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