platform-linux-android.cpp:199:9: error: variable 'r' set but not used [-Werror,-Wunused-but-set-variable]
int r = sem_init(&mMessage2, /* pshared */ 0, 0);
^
platform-linux-android.cpp:206:9: error: variable 'r' set but not used [-Werror,-Wunused-but-set-variable]
not used [-Werror,-Wunused-but-set-variable]
int r = sem_destroy(&mMessage2);
^
Differential Revision: https://phabricator.services.mozilla.com/D126459
This only adds the API and then adds the profiler payload to the buffer. The
deserialization and streaming will happen in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D124026
You can see the `mozilla::MarkerSchema` for the C++ counterpart. This Rust
struct simply wraps the C++ object and keeps the reference of it as RAII. This
heap allocates the inner C++ object but it's fine to do it here, because it's
we only create a MarkerSchema object at the end of a profiling session and it
happens once per marker type. It should be very rare.
Differential Revision: https://phabricator.services.mozilla.com/D124025
This is the first and simplest API for the markers. There will be two more
APIs in the following patches (add_text_marker and add_marker). You can see the
PROFILER_MARKER_UNTYPED macro for the C++ counterpart.
Differential Revision: https://phabricator.services.mozilla.com/D124022
These structs are needed for the marker APIs. We also have the same structs as
the C++ classes. See `mozilla::MarkerTiming` and `mozilla::MarkerOptions`.
Differential Revision: https://phabricator.services.mozilla.com/D124020
Because string contents could be split in two separate chunks, the default ProfilerStringView deserializer needed to concatenate it together in an off-chunk buffer.
But now thanks to ProfileBufferEntryReader::ReadSpans, it is possible to know if the contents are in a single memory area inside one chunk (which should be the vast majority of cases), in which case the ProfilerStringView can just reference it using its internal std::string_view, which saves managing a separate buffer and copying data into it.
However this can only be done safely when the span is correctly aligned for the character type, which may not be the case for char16_t strings that must be even-aligned.
Differential Revision: https://phabricator.services.mozilla.com/D124430
Instead of always having to use `ReadBytes` to copy bytes out of the profile buffer into an external buffer, these functions provide one or two spans (pointer+size) pointing at the area, which can be used to look at the data without copying it, especially in the majority of cases where areas are fully inside one chunk and only need one span to address.
Differential Revision: https://phabricator.services.mozilla.com/D124429
`ProfilerStringView::Data()` would return a pointer to the start of the string, but there may not be a null terminator at the end!
To reduce the likelihood of misuses, that function has now been removed.
Instead, callers must now access the data through `AsSpan` or the `Span` conversion operator (which makes it easy to use with `NS_ConvertUTF16toUTF8` for example).
It was not an issue until now, because deserialized string would always be terminated when copied out of the profile buffer, but a following patch will add optimized code where the non-terminated string inside the buffer will be directly pointed at.
Differential Revision: https://phabricator.services.mozilla.com/D125027
This will allow starting Firefox in the background, and on Windows will allow
closing the last browser window without killing the main process. There is no
plan for actually using this by default in Firefox proper, but it's needed for
some explorations.
There's more to this work that we'll need - this is just the first step. For
instance, we'll need a real way to actually kill firefox on Windows other than
through the task manager (we'll be putting something in the system tray to
allow this.)
The patch wasn't particularly large, so I didn't split out the rename of
MOZ_APP_SILENT_START to MOZ_APP_SILENT_RESTART - let me know if you'd like me
to do that though and I can.
Differential Revision: https://phabricator.services.mozilla.com/D124249
Because string contents could be split in two separate chunks, the default ProfilerStringView deserializer needed to concatenate it together in an off-chunk buffer.
But now thanks to ProfileBufferEntryReader::ReadSpans, it is possible to know if the contents are in a single memory area inside one chunk (which should be the vast majority of cases), in which case the ProfilerStringView can just reference it using its internal std::string_view, which saves managing a separate buffer and copying data into it.
However this can only be done safely when the span is correctly aligned for the character type, which may not be the case for char16_t strings that must be even-aligned.
Differential Revision: https://phabricator.services.mozilla.com/D124430
Instead of always having to use `ReadBytes` to copy bytes out of the profile buffer into an external buffer, these functions provide one or two spans (pointer+size) pointing at the area, which can be used to look at the data without copying it, especially in the majority of cases where areas are fully inside one chunk and only need one span to address.
Differential Revision: https://phabricator.services.mozilla.com/D124429
Because string contents could be split in two separate chunks, the default ProfilerStringView deserializer needed to concatenate it together in an off-chunk buffer.
But now thanks to ProfileBufferEntryReader::ReadSpans, it is possible to know if the contents are in a single memory area inside one chunk (which should be the vast majority of cases), in which case the ProfilerStringView can just reference it using its internal std::string_view, which saves managing a separate buffer and copying data into it.
Differential Revision: https://phabricator.services.mozilla.com/D124430
Instead of always having to use `ReadBytes` to copy bytes out of the profile buffer into an external buffer, these functions provide one or two spans (pointer+size) pointing at the area, which can be used to look at the data without copying it, especially in the majority of cases where areas are fully inside one chunk and only need one span to address.
Differential Revision: https://phabricator.services.mozilla.com/D124429
All the code that uses it was conditioned on ShouldUseProgressivePaint(),
which was changed to always return false in the previous commit.
This also fixes a racy access to this static variable.
Depends on D123712
Differential Revision: https://phabricator.services.mozilla.com/D123713
When starting the profiler, also make a copy of the filter strings
converted to lower-case. This allows caseless comparisons to be made
against thread names without repeatedly converting the filters to
lower-case for each thread.
Differential Revision: https://phabricator.services.mozilla.com/D123302
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
Instead of blindly outputting floating-point numbers of milliseconds, which leads to things like 363.03499999999997, times in ms are now converted to integer number of nanoseconds, stringified, and then manually adjusted to milliseconds again, so we get smaller and friendlier outputs like 363.035.
Eventually, bug 1726675 may change all times to integer number of nanoseconds anyway, but this patch is already helpful in reducing the output, and paves the way by separating the time-output functions from other number outputs.
Differential Revision: https://phabricator.services.mozilla.com/D123329
Sampling overheads are very rarely useful, but they occupy some space during profiling, but also a lot of space in the final JSON profile.
So now they will only be recorded if the environment variable "MOZ_PROFILER_RECORD_OVERHEADS" is set to any non-empty value.
Differential Revision: https://phabricator.services.mozilla.com/D123303
This ensures our users will use the latest version of the frontend when
capturing 'cancel' network markers.
Depends on D123254
Differential Revision: https://phabricator.services.mozilla.com/D123255
Instead of copying the full stack from the previous sample when identical, the new ProfileBufferEntryKind::TimeBeforeSameSample + SameSample entry pair indicates that this is an identical sample. Later when producing the final JSON profile, we can just re-use the same sample identifier as before.
This effectively lowers the size of this kind of entry from hundreds of bytes, down to 20-30 bytes, which should help with capturing more samples in the same buffer size. And it also uses less CPU resources, since we don't need to find the previous stack and copy it.
We still need to perform a full copy at the start of a buffer chunk, to make sure there is always a full stack available in case older previous chunks have been destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D122679
PROFILER_RUNTIME_STATS was broken recently. It's only used during development (mostly to benchmark new code), so it's not critical and no tests are needed.
Differential Revision: https://phabricator.services.mozilla.com/D122677
Per the discussion on governance, the new DLL services module will live in
`toolkit/xre/dllservices`.
Mozglue code will live in `toolkit/xre/dllservices/mozglue` and will be linked
in with `mozglue.dll`.
Differential Revision: https://phabricator.services.mozilla.com/D122384
Per the discussion on governance, the new DLL services module will live in
`toolkit/xre/dllservices`.
Mozglue code will live in `toolkit/xre/dllservices/mozglue` and will be linked
in with `mozglue.dll`.
Differential Revision: https://phabricator.services.mozilla.com/D122384
This hides the scProfilerMainThreadId detail, and makes for a safer API.
Also, ::profiler_init_main_thread_id() calls ::mozilla::baseprofiler::profiler_init_main_thread_id().
And in non-MOZ_GECKO_PROFILER builds, AUTO_PROFILER_INIT calls profiler_init_main_thread_id(), which makes other main-thread functions usable there (assuming profiler_current_thread_id works).
Differential Revision: https://phabricator.services.mozilla.com/D121695
This patch only shuffles source code around, so that all declarations in {,Base}ProfilerUtils.h are now implemented only in ProfilerUtils.cpp (instead of the different platform-*.cpp), the final generated code should be the same in MOZ_GECKO_PROFILER builds (the default on all our supported platforms).
This simplifies the headers and makes further changes easier.
In non-MOZ_GECKO_PROFILER builds: On supported platforms these functions are now fully defined; Unsupported platforms should all had `getpid()`, but thread ids are null.
So now `profiler_current_process_id()` is available on all platforms, at all tier levels.
Differential Revision: https://phabricator.services.mozilla.com/D121051
Since ProfilerProcessId and ProfilerThreadId (and their NumberTypes) will potentially grow to 64 bits on some platforms (in a later patch), all code that uses them must be able to handle bigger types.
Differential Revision: https://phabricator.services.mozilla.com/D121049
When mfplat.dll loads msvp9dec_store.dll, it posts a task
to unload the module to the work queue even if msvp9dec_store.dll
is already loaded and mfplat.dll skips LoadLibrary. Therefore,
we cannot safely lock msvp9dec_store.dll by loading it as data.
The proposed fix is to skip processing the module.
Differential Revision: https://phabricator.services.mozilla.com/D121777
This call appears in the top frames of 2 different stacks (Bug 1723351 and Bug 1723142) so from my understanding it will suppress both test fails. I included both bug numbers for reference.
Differential Revision: https://phabricator.services.mozilla.com/D121546
Previously ProfilingCategoryList.h was a central place for profiling
categories. But with this patch, profiling_categories.yaml becomes the
canonical place for it and the macro header file is being generated
automatically. This is needed to make the profiling categories in sync with
Rust and C++.
Differential Revision: https://phabricator.services.mozilla.com/D120791
We had crashes in `PEHeaders::FindResourceLeaf` where `idDir` was nullptr. This can
happen when the resource table is modified by a third-party application and an entry
in the table points to somewhere outside the executable.
Differential Revision: https://phabricator.services.mozilla.com/D121093
Sanitizers try to intercept __tls_get_addr to find DTLS blocks. In some
cases, they fail miserably with a crash. And in the cases they don't
crash, they don't seem to actually work properly anyways.
This affects both build time when running host programs compiled with
sanitizer flags (this only actually affects rust build
scripts/procedural macros on non-cross builds, not C/C++ host programs),
and execution time, e.g. when running tests.
Differential Revision: https://phabricator.services.mozilla.com/D120574
These classes should replace the `int` type that is currently used to store process and thread ids. The next patches will start using them. Advantages:
- Prevent type mismatches, e.g., giving a process id (or other number) to a function expecting a thread id.
- Prevent nonsensical arithmetic operations.
- Make the unspecified id more abstract, so it's more obvious and portable.
- Make conversions to/from numbers (for display or storage) more visible.
- Allow future changes of APIs using them less risky.
- Allow future changes of the ids themselves (e.g., to be able to use bigger underlying types on some platforms, or even the opaque std:🧵:id type.)
Differential Revision: https://phabricator.services.mozilla.com/D120221
This new header isolates the process and thread functions that should be available in all builds, and in most other profiler headers.
Non-MOZ_GECKO_PROFILER implementations return ids 0 (unspecified process/thread). `profiler_is_main_thread()` returns false, it's arbitrary but consistent with `0` (it makes little sense to use it there anyway.)
Differential Revision: https://phabricator.services.mozilla.com/D120220
The next patch will extract parts of these headers into a separate file, so it's best to do this clean-up now, to best preserve history.
- Add [[nodiscard]] to all functions that return something. (There are no cases where that returned value could really be ignored.)
- Hide scProfilerMainThreadId in a "detail" namespace, to emphasize that it's an implementation detail that the user shouldn't access directly.
- Combine tightly-nested namespaces start/end into single lines, it's more readable.
Differential Revision: https://phabricator.services.mozilla.com/D120219
Originally these includes were wrapped in an ACCESSIBILITY define because the
bug that manifested only affected screen readers. However, theoretically
speaking other things *could* cause us to initialize COM early and run into
troubles, so this is not *strictly* an a11y issue from that perspective. It
wasn't wrapped around ACCESSIBILITY defines inside PreXULSkeletonUI.cpp for
this reason, but there was still lingering inconsistency inside the moz.build
file. This corrects that.
Differential Revision: https://phabricator.services.mozilla.com/D119541
It looks like this suppression was removed downstream, but StartupCache's behavior still exists so it most likely stopped causing failures because of some other suppression interacting with it. I decided the best course of action was to put it back as a perma suppression in gecko in case we run into it again.
Differential Revision: https://phabricator.services.mozilla.com/D119783
This prevents unwanted direct access to the mutex, and removes duplicated code.
And make the Base Profiler mutex&lock consistent.
Differential Revision: https://phabricator.services.mozilla.com/D119147
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
Currently, we set DPI awareness in the manifest files for firefox.exe.
Unfortunately, that causes DPI-related Win32k calls when user32.dll
is loaded.
This changes things to wait until we are sure we're not running in a
Win32k Lockdown Content Process before we attempt to initialize DPI scaling.
Differential Revision: https://phabricator.services.mozilla.com/D116433
This reverses bug 1703410: By default the profiler now changes the timer resolution (normally 64Hz) when the requested sampling interval is lower than 10ms, to allow fast-enough sampling for most uses.
But since this can influence other timers in Firefox, it makes debugging some types of issues more difficult. To help with this, there is now a "No Timer Resolution change" on Windows, which prevents the profiler from changing the timer resolution, at a risk of slowing down sampling in some processes.
Differential Revision: https://phabricator.services.mozilla.com/D117626
Currently, we set DPI awareness in the manifest files for firefox.exe.
Unfortunately, that causes DPI-related Win32k calls when user32.dll
is loaded.
This changes things to wait until we are sure we're not running in a
Win32k Lockdown Content Process before we attempt to initialize DPI scaling.
Differential Revision: https://phabricator.services.mozilla.com/D116433
Currently, we set DPI awareness in the manifest files for firefox.exe.
Unfortunately, that causes DPI-related Win32k calls when user32.dll
is loaded.
This changes things to wait until we are sure we're not running in a
Win32k Lockdown Content Process before we attempt to initialize DPI scaling.
Differential Revision: https://phabricator.services.mozilla.com/D116433
When a module is loaded with `LOAD_LIBRARY_AS_IMAGE_RESOURCE`, the mapped region
is `MEM_IMAGE`, but it's not executable. We don't have to check the blocklist
in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D117573
BP may contain the stack address where the caller's BP was pushed after the function call, in which case it's possible to carefully unwind from it.
This can get past JIT code, so there is no need to give up in this case.
mozglue was already linked with ntdll, but now that we use it directly (for `NtQueryInformationThread`), ntdll needed to be added to some other users of MozStackWalkThread.
Differential Revision: https://phabricator.services.mozilla.com/D115962
On Windows, the profiler changes the timer resolution when the sampling interval is less than 10ms.
However this change affects all of Firefox, which can change other behaviors, sometimes causing confusion when refresh-rate issues magically disappear when the profiler is running.
So now by default the profiler will not change the timer resolution. This should rarely affect the profiler's effective sampling rate, unless all threads in a process are in a waiting state, in which case there is nothing new to sample anyway! The front-end is investigating ways to make sampling gaps more obvious, see https://github.com/firefox-devtools/profiler/issues/2962
If some power users really need the added sampling precision in some profiling sessions, the timer resolution change may be requested before running Firefox, by setting the environment variable "PROFILER_ADJUST_TIMER_RESOLUTION" to any value.
Differential Revision: https://phabricator.services.mozilla.com/D115451
`SharedLibraryInfo::GetInfoForSelf()` can use `PEHeaders::GetBounds` instead of
`GetModuleInformation` to get the start/end address of a module's mapped region
in the local process. It's roughly 100x faster because `GetModuleInformation`
invokes two system calls `NtQueryInformationProcess` and `NtReadVirtualMemory`
while `nt::PEHeaders` does not.
Depends on D115254
Differential Revision: https://phabricator.services.mozilla.com/D115255
This patch replaces two versions of `GetVersion` in Gecko profiler and
baseprofiler with `PEHeaders::GetVersionInfo`.
Depends on D115253
Differential Revision: https://phabricator.services.mozilla.com/D115254
This patch is the actual fix for Bug 1702086. The problem of Bug 1702086 is that
`LoadLibraryExW` loaded the module onto an address different from the original
mapped addresss because it was unloaded after we started enumeration. Calling
`GetPdbInfo` with the original address `module.lpBaseOfDll` caused a crash.
The proposed fix consists of three parts.
The first part is to get PDB information from `handleLock`, which is always valid
even if the original address was unloaded. With this, we don't need a check
of `VirtualQuery`.
The second part is to add `LOAD_LIBRARY_AS_IMAGE_RESOURCE` along with
`LOAD_LIBRARY_AS_DATAFILE` to the call to `LoadLibraryEx`. This is needed
to read information from the sections outside the PE headers because
RVA (= relative virtual address) is an address after relocation.
Without `LOAD_LIBRARY_AS_IMAGE_RESOURCE`, a module is mapped without relocation,
so `GetPdbInfo()` accesses wrong memory resulting in a crash.
The third part is to introduce `PEHeaders::GetPdbInfo`, replacing two versions
of `GetPdbInfo` in Gecko profiler and baseprofiler.
Depends on D115252
Differential Revision: https://phabricator.services.mozilla.com/D115253
This patch introduces `EnumerateProcessModules` to enumerate all loaded modules
in the local process so that Gecko profiler and baseprofiler can use it.
Differential Revision: https://phabricator.services.mozilla.com/D115252
SprintfLiteral doesn't support "%#llx" anymore.
So this patch switches to an explicit "0x%llx" to output addresses as the symbolicator expects.
Differential Revision: https://phabricator.services.mozilla.com/D114914
When the linker defaults to --as-needed, libmozgtk ends up not linked
to libxul because libxul doesn't use anything from it.
We solve the problem by adding a symbol to mozgtk and have libxul use
it.
In bug 1377445, we moved XShmQueryExtension to mozglue. While libxul
currently doesn't use the symbol (it's a workaround for system
libraries), we can move the function back to mozgtk and add a dummy
call.
Differential Revision: https://phabricator.services.mozilla.com/D113487
Instead of lots of #ifdef's inside WalkStackMain64 to access CONTEXT registers with their platform-specific names, these registers are now accessible through generic accessors in the wrapper class.
This also helps with avoiding CONTEXT pointers (and the worry they could be null).
Differential Revision: https://phabricator.services.mozilla.com/D112168
Bug 1620118 added a new field `isDependent` in the third-party-module ping
which is calculated in `UntrustedModulesProcessor`. However, bug 1684532
revealed it was not accurate because some third-party applications revert
the import table to the original state immediately after their module was
loaded.
Now that we have a logic to determine `isDependent` in `NtMapViewOfSection`
to automatically block a module injected through the import table, we can
pass that value to the ping and remove the original logic in `UntrustedModulesProcessor`.
Differential Revision: https://phabricator.services.mozilla.com/D112227
This is a little more than we need to disable it, but I figure we'll want to
support different UI densities in the skeleton UI long term.
Differential Revision: https://phabricator.services.mozilla.com/D111906
This is a little more than we need to disable it, but I figure we'll want to
support different UI densities in the skeleton UI long term.
Differential Revision: https://phabricator.services.mozilla.com/D111906
When restarting, we set the XRE_PROFILE_PATH env var. This normally would
prevent us from showing the skeleton UI. This patch just adds another env
var to indicate that we are restarting so the skeleton UI can know it's
safe to display.
Differential Revision: https://phabricator.services.mozilla.com/D111884
We specify our colors like 0xrrggbb, but CreateSolidBrush expects a
color created with the RGB macro, which actually arranges it as
0xbbggrr. This change has us use the RGB macro to give a color when
creating the brush.
Differential Revision: https://phabricator.services.mozilla.com/D107945
WASI lacks of support many memory stuff like mmap, memory protections and etc, but
it has malloc so we can use it instead. Also, here we are stubbing out all
uses of the missing WASI memory functionality.
Differential Revision: https://phabricator.services.mozilla.com/D110075
WASI lacks of support many memory stuff like mmap, memory protections and etc, but
it has malloc so we can use it instead. Also, here we are stubbing out all
uses of the missing WASI memory functionality.
Differential Revision: https://phabricator.services.mozilla.com/D110075
Before `SharedLibraryInfo::GetInfoForSelf` calls `GetPdbInfo` to parse a module's
PE header, it calls `LoadLibraryEx` to prevent the module from being unloaded
during `GetPdbInfo`. If the module was already unloaded before `LoadLibraryEx`,
however, `LoadLibraryEx` maps the module onto an address different from the original
mapped address, so that `module.lpBaseOfDll` becomes invalid.
This patch is to call `LoadLibraryEx` before `GetModuleInformation` to make sure
`LoadLibraryEx` increments the module's refcount and does not map the module onto
a new address. With this, `module.lpBaseOfDll` is always valid, thus we don't have
to call `VirtualQuery`.
Differential Revision: https://phabricator.services.mozilla.com/D110421
WalkTheStack* is the function that is being called to print stacks to
the user on e.g. MOZ_CRASH on debug builds. Until bug 1699375, some
cases weren't covered, which now cause unwanted side-effects with e.g.
fuzzing. At least as a stop-gap, allow to runtime-disable the behavior
via an environment variable.
Other uses of the stack-walker, like the profiler's, are not affected
when setting the environment variable.
Differential Revision: https://phabricator.services.mozilla.com/D110199
Lastly, we are changing the parts that requires a version bump and bumping the
profiler version in the end. This will require a PR in the front-end for a
version upgrader and changes related to the renaming.
Differential Revision: https://phabricator.services.mozilla.com/D109282
This patch is only about renaming the internals of the profiler codebase and
it doesn't touch any parts that requires a backwards compatibility or version
bump.
Differential Revision: https://phabricator.services.mozilla.com/D109280
- Add missing include directives and forward declarations.
- Remove some extra include directives.
- Add missing namespace qualifications.
- Move include directives out of namespace in toolkit/xre/GlobalSemaphore.h
Differential Revision: https://phabricator.services.mozilla.com/D98894
This commit adds a new command line option |-xpcshell| that, when passed, will
run an xpcshell instead of launching a full Gecko instance.
This command line option is restricted to org.mozilla.geckoview.test for now,
as it's really hard to use and not really a usecase outside mozilla. We can
revisit this if there's interest.
Differential Revision: https://phabricator.services.mozilla.com/D106211
This commit adds a new command line option |-xpcshell| that, when passed, will
run an xpcshell instead of launching a full Gecko instance.
This command line option is restricted to org.mozilla.geckoview.test for now,
as it's really hard to use and not really a usecase outside mozilla. We can
revisit this if there's interest.
Differential Revision: https://phabricator.services.mozilla.com/D106211
A long standing issue is that MOZ_ASSERT and related don't print stack
traces in debug builds when they're directly or indirectly emitted from
non-libxul code. Moving WalkTheStack to mozglue alleviates the problem.
It's also not printing stack traces when emitted from C code (and for
some C third party libraries, we do redirect assert to MOZ_ASSERT),
which we solve by making the corresponding API available without C++
(which WalkTheStack being a static method of the nsTraceRefCnt class
didn't allow, or the use of a closure on Android).
This requires some adjustements to headers that indirectly assume that
Assertions.h includes ErrorList.h through nsError.h through nscore.h
through nsTraceRefcnt.h.
We also remove TestStackCrawl.cpp because it hasn't been built since
bug 158528, 19 years ago.
Differential Revision: https://phabricator.services.mozilla.com/D108913
It requires including <windows.h>, preventing the inclusion of StackWalk.h
from some places (and upcoming changes will make StackWalk.h included in
more places).
Differential Revision: https://phabricator.services.mozilla.com/D108910
In the case of FramePointerStackwalk, the caller gives a pointer to the
top-most frame to walk from. There isn't really a reason to give a
number of frames to skip, as the right frame pointer could be given in
the first place if that was really necessary. And in practice, it's
hasn't been used so far.
In the case of MozStackWalkThread, the caller presumably doesn't know
what the thread the stack is being walked for is doing, and it would be
a guesswork to pass a valid number of frames to skip. In practice, it's
also not used.
The aSkipFrames is already a footgun on MozStackWalk (and we're going to
change that in bug 1515229), we don't need to keep a footgun on these
other stack walking methods.
Differential Revision: https://phabricator.services.mozilla.com/D108563
Currently, printf_stderr doesn't show up when running with ./mach run.
This is because we run with -attach-console and that redirects stderr
to a different file descriptor using freopen in UseParentConsole.
The change from just using stderr directly happened in bug 340443 and was done
to avoid some linking issues. That problem doesn't seem to apply anymore so you'd
expect we'd be able to go back to the straightforward implemention that works even
if stderr has been redirected. Unfortunately, Windows takes not buffering
stderr very seriously and fprintf will write out the results character
by character. This can cause log output lines to be intermixed which
breaks log parsing in CI. We keep using fdopen to create a new FILE*
that's buffered but instead of hard coding fd 2, we get the actual fd
that corresponds to stderr using fileno.
The mozglue implementation was cargo culted from xpcom, so we update it
as well.
Differential Revision: https://phabricator.services.mozilla.com/D98550
This patch makes sure the repo can be built without `MOZ_LAUNCHER_PROCESS`.
- Compile WinTokenUtils.cpp under winlaucher regardless of `MOZ_LAUNCHER_PROCESS`
because we still need `IsAdminWithoutUac`.
- Skip TestDllBlocklist.NoOpEntryPoint GTest because the `RedirectToNoOpEntryPoint`
feature is only available with the new blocklist with the launcher process.
Differential Revision: https://phabricator.services.mozilla.com/D108142
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses, and the updater, for which we keep using vsnprintf.
Differential Revision: https://phabricator.services.mozilla.com/D103730
This code is important for transitioning between the skeleton UI code and the
full-featured browser window code. Additionally, the original logic of disabling
when not on the default theme no longer applies, because it was intended to
eliminate white flashes in dark mode. However, with the skeleton UI, those
white flashes no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D107293
If we error out in, say, DrawSkeletonUI, the window we created will be orphaned
and left to sit there indefinitely. This patch fixes that by separating the
error from the consume result.
Differential Revision: https://phabricator.services.mozilla.com/D107301
We know that some GV installations (particularly but not exlcusively Focus) are
failing to load `libxul.so` during early Gecko bootstrapping. Unfortunately
a boolean pass/fail result is not giving us sufficient information to be able to
properly troubleshoot this problem.
This patch adds `mozilla::Result`-based return values to `XPCOMGlueLoad` and
`GetBootstrap` in an effort to produce more actionable information about these
failures.
We include either a `nsresult` or, if the failure is rooted in a dynamic linker
failure, appropriate platform-specific error information:
* On Unix-based platforms, a `UniqueFreePtr<char>` containing the string from `dlerror(3)`;
* On Windows, the Win32 `DWORD` error code from `GetLastError()`.
For non-Android platforms, I updated them to handle the new return type, but
otherwise did not make any further changes.
For Android, we include the error information in the message string that we pass
into the Java `Exception` that is subsequently thrown.
Differential Revision: https://phabricator.services.mozilla.com/D104263
No code changes.
Build issues were found by renaming `MOZ_GECKO_PROFILER` to something else in toolkit/moz.configure, in both unified and non-unified builds, on all supported platforms.
Also updated some profiler-related comments.
Differential Revision: https://phabricator.services.mozilla.com/D105375
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses.
Differential Revision: https://phabricator.services.mozilla.com/D103730
