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
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
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
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 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
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
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
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
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
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
New headers BaseProfilerLabels.h and ProfilerLabels.h now contain all label-related APIs.
These files were hg-copied from the main headers, to preserve history, and then non-label content was removed from the main headers.
The "RAII" macros were moved to these *ProfilerLabels.h headers, because that's the most-common header in which they're needed. Meta-bug 1681416 will probably move these again as needed.
Differential Revision: https://phabricator.services.mozilla.com/D104587
{Base,}ProfilerMarkers.h can now rely on {Base,}ProfilerState.h (and just one function forward declaration), so they don't need to include {Base,Gecko}Profiler.h anymore.
Thanks to that, {Base,Gecko}Profiler.h can now include {Base,}ProfilerMarkers.h at the top.
Also, BaseProfilingStack.h should not include BaseProfiler.h (include loop, can cause failures) not algorithm (not used).
***
roll up into 2nd patch
Differential Revision: https://phabricator.services.mozilla.com/D104969
New headers BaseProfilerState.h and ProfilerState.h now contain most state-reading APIs.
These files were hg-copied from the main headers, to preserve history, and then chosen declarations were kept only in the relevant header.
This is needed in a following patch, where new headers *ProfilerLabels.h use `profiler_is_active()`.
Differential Revision: https://phabricator.services.mozilla.com/D104968
ProfileBufferCollector::SamplePositionInBuffer() and BufferRangeStart() need to provide indices in the same main buffer, because they will be used to discard old data (at some previous `SamplePositionInBuffer`) once the `BufferRangeStart` indicates that it is not referenced by the profiler anymore.
Because the periodic sampler uses a local buffer (to avoid allocations and locks), we need to record the special location from the main profiler buffer in ProfileBufferCollector.
Differential Revision: https://phabricator.services.mozilla.com/D104497
The `RunningTimes` class stores CPU measurements. It may seem overkill for only one value, but in the future more measurements will be added.
During sampling, CPU measurements are collected by platform-specific code. This patch doesn't produce anything yet, see later patches.
These are stored with the samples.
Note that for duplicated samples (when a thread is known to be "asleep"), we still need to collect new measurements, because there could potentially be some activity happening, e.g. in system calls.
Finally the measurements are output as extra "samples" values.
Units for these values may platform-specific, so they are stored in the top-level JSON "meta" object.
We don't collect running times in the Base Profiler (yet), but we still need to add the appropriate field names in the samples' "schema", as expected by profiler.firefox.com.
Differential Revision: https://phabricator.services.mozilla.com/D99413
Toshihito Kikuchi
Nazım Can Altınova
Gerald Squelart
Florian Quèze
Tom Ritter
Iulian Moraru
Andi-Bogdan Postelnicu
Alexandru Michis
Jeff Muizelaar
Mike Hommey
Markus Stange
Greg Tatum