`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 adds a test that goes through all combinations of a number of important features, and verifies that the JSON output looks valid.
Differential Revision: https://phabricator.services.mozilla.com/D124739
All profiles submitted to `JSONOutputCheck` are now checked for valid-looking samples, as in:
- Samples should point into the stackTable.
- stackTable entries should point to the caller in the same stackTable (or null for the root frame).
- stackTable entries should also point into the frameTable.
- frameTable entries should point into the stringTable for the "location".
Differential Revision: https://phabricator.services.mozilla.com/D124738
A scenario for a thread may be that the first entry has an empty sample (usually if stack-sampling is turned off) and no running times (first-ever sample, or "cpu" is off), so it's not output, and there is no corresponding stack table entry.
Then there may be a "same sample" entry.
- If there are no running times, nothing should be output.
- If there are running times, an empty stack should be output, but for that we need to ensure that the root frame is present in the stack table entry, because that represents an empty stack.
Differential Revision: https://phabricator.services.mozilla.com/D124612
This adds a test that goes through all combinations of a number of important features, and verifies that the JSON output looks valid.
Differential Revision: https://phabricator.services.mozilla.com/D124739
All profiles submitted to `JSONOutputCheck` are now checked for valid-looking samples, as in:
- Samples should point into the stackTable.
- stackTable entries should point to the caller in the same stackTable (or null for the root frame).
- stackTable entries should also point into the frameTable.
- frameTable entries should point into the stringTable for the "location".
Differential Revision: https://phabricator.services.mozilla.com/D124738
A scenario for a thread may be that the first entry has an empty sample (usually if stack-sampling is turned off) and no running times (first-ever sample, or "cpu" is off), so it's not output, and there is no corresponding stack table entry.
Then there may be a "same sample" entry.
- If there are no running times, nothing should be output.
- If there are running times, an empty stack should be output, but for that we need to ensure that the root frame is present in the stack table entry, because that represents an empty stack.
Differential Revision: https://phabricator.services.mozilla.com/D124612
Both work, but the former is preferred. Also remove MOZ_MAKE_FLAGS
in the mozconfig example for msan, because it's irrelevant.
Differential Revision: https://phabricator.services.mozilla.com/D124726
This also adds a commented out option for automatically fixing use-services in the ESLint rule. This cannot be enabled at the moment as it needs special treatment for chrome tests.
Differential Revision: https://phabricator.services.mozilla.com/D124391
We've overloaded "bootstrap" to mean three different things:
* The "standalone bootstrap script": `python/mozboot/bin/bootstrap.py`.
This is to freshly clone a new repo, then run `./mach bootstrap`.
* `./mach bootstrap`: Install necessary dependencies and set up the
system for development.
* "Mach bootstrap": do the in-process initialization work Mach needs
before it can run commands.
By using the term "initialize" instead, perhaps we can remove
ambiguity when discussing Mach.
I'm not attached to the name (or this change at all), but I'm interested
in reviewer thoughts :)
Differential Revision: https://phabricator.services.mozilla.com/D120410
This update makes wgpu a vendored dependency instead of having it in gfx/wgpu.
## Notes
It relies on https://phabricator.services.mozilla.com/D123157
It has a quirk related to OpenGL ES backend. Previousy, we manually had to disable GL backend
in order to avoid vendoring WASM dependencies in. This time, manual editing is more complicated,
so instead this change adds a few cargo patch lines to point WASM dependencies to dummy projects.
The update also totally removes SPIRV-Cross, since the latest `wgpu` doesn't depend on it any more.
The compiled binary size for Gecko should improve with this.
Differential Revision: https://phabricator.services.mozilla.com/D123153
The lock in the inner `profiler_suspend_and_sample_thread` function was only needed on the `!aIsSynchronous` code path.
So instead, the pointer to the lock is passed in this case, otherwise `nullptr` indicates a synchronous (same-thread) sampling.
Differential Revision: https://phabricator.services.mozilla.com/D123915
Since bug 1722261, thread registrations are not tied to CorePS anymore, ThreadRegistry stores them in a static list.
Also, profiler_register_thread immediately calls ThreadRegistration::RegisterThread -> ThreadRegistration constructor -> ThreadRegistry::Register, which checks if there is a CorePS before working with it.
So this assertion can safely be removed now.
In rare instances, `CorePS` may not actually exist (profiler not initialized yet, or already shutdown), and this assertion could trigger and report an unimportant crash.
Differential Revision: https://phabricator.services.mozilla.com/D123912
The buffer was previously allocated as soon as a JSContext was present, meaning that some memory was used even when the profiler was not running, which is the case most of the time for most users.
This saves some memory, at the cost of having to lock the per-thread ThreadRegistration data when sampling a thread with a JSContext. This should have low contention risk, because it's mostly used when sampling on the thread, while the periodic sampler uses its own buffer so it doesn't need to lock the per-thread data.
Differential Revision: https://phabricator.services.mozilla.com/D123910
Running the profiler while Firefox runs in rr sometimes crashes, and it seems the SP register is far from the known stack area (ending at StackTop), which then proceeds to copy some protected memory.
Note that there was already a `start < end` test, this patch adds an equivalent test on the other side, allowing for a 1MB stack size. Observed stacks during quick testing were up to around 520KB, and the crashing rr case was in the trillions(!), so 1MB should be an appropriate number that should catch "wrong" SPs while allowing real stacks.
Differential Revision: https://phabricator.services.mozilla.com/D123605
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
`profiler_capture_backtrace_into` now only uses thread-safe functions: ThreadRegistration::WithOnThreadRefOf, Register::SyncPopulate, DoSyncSample.
So we don't need to lock the main profiler mutex anymore.
This means that on-thread sampling (typically used in markers) can happen at the same time the periodic sampler has locked the profiler mutex and is sampling this and other threads.
Differential Revision: https://phabricator.services.mozilla.com/D122089
Since these functions don't need to access profiler functions requiring a lock, they themselves don't need that lock anymore.
Differential Revision: https://phabricator.services.mozilla.com/D122088
MergeStack requires a fairly large buffer to store JS frames, too big to be allocated on the stack without risking a stack overflow.
Until now, there was only one buffer, stored in CorePS, and only accessible while holding the Profiler gPSMutex.
Now each thread that has a JSContext, also has its own JS frame buffer, which is accessible on the thread without needing any lock.
The Profiler's Sampler still uses the CorePS buffer for its periodic sampling, but it won't prevent parallel on-thread sampling anymore.
The appropriate buffer is passed to ExtractJsFrames and then MergeStacks.
MergeStacks accepts a null pointer, which happens on threads where there is no JSContext, and therefore no JS to sample.
Differential Revision: https://phabricator.services.mozilla.com/D122087
Andrew Halberstadt
Sylvestre Ledru
Renovate Bot
Sylvestre Ledru
Gabriele Svelto
Mark Banner
Gerald Squelart
Noemi Erli
Mike Hommey
Andrew Halberstadt
Cristian Tuns
Mitchell Hentges
Dzmitry Malyshau
Nazım Can Altınova
Benjamin Peterson
Belén Albeza
Julian Descottes
Joel Maher
Marco Castelluccio
Marian-Vasile Laza
Christopher Winter
Andi-Bogdan Postelnicu