On Linux and Android, both jitdump and the marker file will keep using
`CLOCK_MONOTONIC` nanoseconds, as before.
On macOS, both jitdump and the marker file will now be using
`TimeStamp::RawMachAbsoluteTimeNanoseconds()` , i.e. "nanoseconds since
mach_absolute_time origin".
This value has the advantage that it is also relatively easy to obtain
in other browser engines, because their internal timestamp value is stored
in milliseconds or nanoseconds rather than in `mach_absolute_time` ticks.
In the past, on macOS, Firefox was using `CLOCK_MONOTONIC` nanoseconds for
jitdump and `TimeStamp::RawMachAbsoluteTimeValue()` for the marker file.
This inconsistency is now fixed.
I will update samply to change how it treats jitdump timestamps on macOS.
There are no other consumers of jitdump files on macOS that I know of.
On Windows, we will keep using raw QPC values for the marker file - this
matches what's in the ETW events. Jitdump on Windows is mostly unused but
I'm updating it to match.
Furthermore, this fixes the order in mozglue/misc/moz.build to make sure
we always use the TimeStamp_darwin implementation on Darwin (and not just
due to a broken configure check, see bug 1681445), and it fixes the #ifdef
in TimeStamp.h to match the Darwin check.
Differential Revision: https://phabricator.services.mozilla.com/D199592
This adds code to emit ETW markers on windows. It supports all current
markers through a generic marker emitting schema. It also supports
additional payload and filtering for any markers that are updated to a
new compile-time marker schema system. Because of our abstraction layer
and cross-platform nature we have to manually create the TraceLogging
structs used and can't rely on their macro's, but this should give us a
very flexible and performant marker implementation on ETW.
Differential Revision: https://phabricator.services.mozilla.com/D196331
EnsureDbgHelpInitialized() and EnsureSymInitialized() can currently
cause deadlocks through reentrancy in DEBUG and FUZZING builds, through
MOZ_ASSERT and MOZ_CRASH failures. This patch merges these functions
into a single InitializeDbgHelp() reentrancy-safe function.
Differential Revision: https://phabricator.services.mozilla.com/D196421
In the fx codebase, we tend to use __attribute__((naked)) for plain
assembly functions with a C interface. Instrumenting these functions can
mess up this assembly, so we conservatively also want to prevent
instrumentation.
Differential Revision: https://phabricator.services.mozilla.com/D196154
Otherwise injected code, under temporal profiling, messes up the inline
assembly used by the wrapper. Ideally, we would use extended asm to
correctly state the constraint, but it is incompatible with naked
functions.
See discussion in https://github.com/llvm/llvm-project/issues/74573 for
the interaction between ``naked`` and profiling.
Differential Revision: https://phabricator.services.mozilla.com/D195315
In order to investigate LoadLibraryW failures in bug 1851889, we make
LoadLibraryOrCrash collect ntdll.dll single step data in utility
processes. The data will be available in the stack of the crashing
thread in nightly and early beta builds.
Single-step data collection only occurs after a first failure to load
the library, when we would be about to crash anyway. This ensures that
the patch cannot introduce extra unstability to LoadLibraryOrCrash.
Single-stepping through all ntdll instructions would record too many
steps, so we add the capability to record only call and ret
instructions. We apply this new capability for the single-step recording
of LoadLibraryW. Thanks to the detection of error state changes, this
should help us identify what path leads to a 0x241 last error in
bug 1851889.
Depends on D194203
Differential Revision: https://phabricator.services.mozilla.com/D194204
This patch makes the single-step data collection code that we
implemented for bug 1571516 reusable, while preserving its behavior.
We define a generic CollectSingleStepData function that embeds the
magic for starting to trigger single step exceptions and for acting upon
them.
We define a more specialized CollectModuleSingleStepData function which
can be reused if the purpose of single step data collection is to
monitor what paths are taken within a specific module. It stores the
collected data in stack, so that it can be accessed from crash reports.
This code is considered unstable and thus only available in Nightly and
early Beta and only used on paths that are known to crash already.
Differential Revision: https://phabricator.services.mozilla.com/D194203
SymInitialize can fail with ERROR_INVALID_PARAMETER if some other piece
of code has already called it with the handle value that we are
providing. Therefore it is not recommended to pass GetCurrentProcess()
to this function. Instead, this patch duplicates the handle for the
current process, so that we can pass a unique handle to the current
process and thus avoid collision with handle values that other
components might pass to SymInitialize.
Differential Revision: https://phabricator.services.mozilla.com/D189360
Stack walking can currently produce crashes when we fail to delay-load
DbgHelp.dll. This patch ensures that the library is already loaded in
the process before we try to call any delay-imported function from it.
The patch also improves thread-safety for our DbgHelp initialization
code.
Differential Revision: https://phabricator.services.mozilla.com/D188956
We currently fail to guarantee that OnEndDllLoad is called on the same
gLoaderObserver as OnBeginDllLoad. We must implement additional
synchronization to prevent a race condition where a call to
LoaderPrivateAPIImp::SetObserver would come in between the two and
change gLoaderObserver.
This has led to issues when using MOZ_PROFILER_STARTUP=1 where we would
have sStackWalkSuppressions reach (size_t)-1 instead of 0, later
resulting in deadlock or missing stacks. See bug 1687510 comment 10 for
extra details.
Depends on D181436
Differential Revision: https://phabricator.services.mozilla.com/D181437
On Windows aarch64 and x64 builds, stack walking relies on
RtlLookupFunctionEntry. This can lead to deadlock, which we avoid in x64
builds by adding stack walking suppressions. We must do the same in
aarch64 builds to avoid the same deadlock situation, but we are
missing some stack walk suppression paths. Let's fix that.
Differential Revision: https://phabricator.services.mozilla.com/D181435
When a first hang is detected, the BHMgr Monitor thread needs to commit
5 more pages of stack to run profiler_suspend_and_sample_thread, which
contains big stack variables. If that occurs while we are low on memory,
failure to commit stack pages can crash the process.
In bug 1716727, we have added delays on failed allocations to try
to avoid crashing the main process under low memory condition. These
delays could trigger the background hang monitor, which could in
turn crash the process, as they occur in a low memory condition where we
will likely fail to commit.
We can pre-commit the 5 pages of stack at thread initialization to
ensure that they will already be commited when we later need them. Or at
least, we can try to see if that works.
We do that with a wrapper for the __chkstk function. We add a new test
in the NativeNt cppunit test, to ensure that our wrapper function
behaves as expected.
Differential Revision: https://phabricator.services.mozilla.com/D182582
Bug 1596930 added support for detouring a pattern of code used by eScan
Internet Security Suite. The patch also added tests to make sure
that we correctly detour this pattern.
The pattern involves a PUSH instruction followed by a RET instruction.
This pattern is forbidden by Intel CET, which enforces at RET time that
we always return to an address that was pushed on the stack by a
prior CALL instruction. Executing the pattern thus crashes if Intel CET
is active.
If CET is active, we must thus skip the execution part of the test, or
the test crashes. We will still check that our detouring code
recognized the pattern and detoured it, but we will not run the detoured
pattern anymore under active Intel CET.
Differential Revision: https://phabricator.services.mozilla.com/D163468
By coupling the state of `signwidth` and `sign`, we provide enough
information to the compiler for it to get rid of an extra mov as a
result of `-ftrivial-auto-var-init`.
Differential Revision: https://phabricator.services.mozilla.com/D187047
This requires to make existing Decimal constructor constexpr, which is
incompatible with the weak linkage implied by MFBT_API.
As an alternative, provide a constexpr user-defined-literal that creates
a temporary DecimalLiteral that can be used by a new Decimal constexpr
constructor.
Differential Revision: https://phabricator.services.mozilla.com/D184552
Mingw trunk recently gained the missing pieces we were #define'ing.
Unfortunately, the way we were doing that is not compatible with them
being there now, so we change it so that it works with both the current
version of mingw we use, and trunk by:
- using a typedef for HREPORT instead of a #define, which is the same
declaration as in trunk
- because PWER_SUBMIT_RESULT is a typedef with the underlying
WER_SUBMIT_RESULT type defined inline, we can't typedef it.
Fortunately, there's only one thing using PWER_SUBMIT_RESULT in the
old version of werapi.h in mingw (WerReportSubmit), so we #define
it to change its definition instead.
- WER_MAX_PREFERRED_MODULES_BUFFER is a #define without parens in
the new header, which would conflict, but #define'ing to the same
value as in the new header, without the parens makes it work.
Differential Revision: https://phabricator.services.mozilla.com/D186412
We have discovered that clock_gettime(CLOCK_MONOTONIC) can be slow on
certain arm64 devices due to Linux kernel workarounds for CPU errata
avoiding the VDSO fast-path. Using CLOCK_MONOTONIC_COARSE is
unnaffected by these issues. This patch adds an implementation of
TimeStamp::NowLoRes() using the coarse clock, meaning that when lower
precision timestamps are adequate we do not pay the penalty of hitting
the slow path.
CLOCK_MONOTINIC_COARSE is Linux-specific, therefore its usage is
guarded by ifdefs as well as at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D185004
This also does minimal refactoring of cases where the directives were
protecting a simple expression that could be refactored back to the
callers.
Differential Revision: https://phabricator.services.mozilla.com/D184399
This also does minimal refactoring of cases where the directives were
protecting a simple expression that could be refactored back to the
callers.
Differential Revision: https://phabricator.services.mozilla.com/D184399
In their previous versions, TimeStamp comparisons were unexpectedly
expensive on Windows. With this change, for example,
TimeoutManager::Timeouts::Insert() cost goes down by at least 12% in my
stress test.
Differential Revision: https://phabricator.services.mozilla.com/D182675
With bug 1832467 we have updated our Windows SDK version to 10.0.19041.
As a result, we now have a .retplne section in xul.dll, starting with
Firefox 115. This is a section with PAGE_NOACCESS protection, so
accessing it crashes the process.
Some injected DLLs read the whole memory space dedicated to the xul.dll
image to search for patterns in it. When they hit the .retplne section,
we will crash. This happened for a legit product in bug 1837242, but
also for a malicious DLL in bug 1841751. This is a startup crash.
This changeset blocks the variants of this malicious DLL we know, to
eliminate the associated startup crash spike. Because the DLL does not
use a fixed name, we block by matching on the combination of version
number + timestamp + image size, based on the values found in crash
reports. We additionnally check for a checksum of 0 and the absence of
debug information, both of which are uncommon for legit production-ready
DLLs; this thus helps further reduce the chances of collision.
Differential Revision: https://phabricator.services.mozilla.com/D183096