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
Toshihito Kikuchi
Harry Twyford
Kris Wright
Doug Thayer
Mike Hommey
Nazım Can Altınova
Brindusan Cristian
Andrew Osmond
Gerald Squelart
Florian Quèze
Mike Kaply
Tom Ritter
Markus Stange
Narcis Beleuzu
Dorel Luca
Chris Martin
Iulian Moraru
Noemi Erli