Once the buffers are combined, some data could be stored in a thread before its registration with the Gecko Profiler.
Without this fix, the front-end would think the thread had not started yet, which could prevent interacting with that early data.
Differential Revision: https://phabricator.services.mozilla.com/D138239
Once the buffers are combined, a RequestedChunkRefCountedHolder could be referenced from the Base Profiler, which is invisible to the leak catcher; then handed over to the Gecko Profiler where it will eventually be dereferenced, which is logged with the leak catcher, resulting in an apparent negative leak.
This is fixed by keeping all (de)references secret.
Differential Revision: https://phabricator.services.mozilla.com/D138238
With the latest Windows 10 SDK (10.0.20348.0), the value of NAN has changed
to differ from the STL. We intentionally #undef the value gotten from the SDK
and replace it with the STL value so that the comparison tests pass regardless
of the Windows SDK version.
Differential Revision: https://phabricator.services.mozilla.com/D137598
When trying to profile only one process, the profiler should not even start in those processes excluded by the filter, so that they don't use any resources (memory and CPU).
To do that, the filter is checked for "pid:" at the multiple locations it may appear:
- In the parent process, when starting the overall profiler, don't send the "Start" IPC to excluded processes.
- When a new process starts and initializes the profiler, don't start the profiler if the filter excludes this process.
- When a new process then registers itself with the parent, don't (re)start the profiler in excluded processes.
Child processes that don't run the profiler may still be asked for a JSON profile at the end of the profiling session. This is handled by sending an empty string, so that the parent process will correctly remove them from the pending-profile list.
Differential Revision: https://phabricator.services.mozilla.com/D135854
When trying to profile only one process, the profiler should not even start in those processes excluded by the filter, so that they don't use any resources (memory and CPU).
To do that, the filter is checked for "pid:" at the multiple locations it may appear:
- In the parent process, when starting the overall profiler, don't send the "Start" IPC to excluded processes.
- When a new process starts and initializes the profiler, don't start the profiler if the filter excludes this process.
- When a new process then registers itself with the parent, don't (re)start the profiler in excluded processes.
Child processes that don't run the profiler may still be asked for a JSON profile at the end of the profiling session. This is handled by sending an empty string, so that the parent process will correctly remove them from the pending-profile list.
Differential Revision: https://phabricator.services.mozilla.com/D135854
Add `ProgressLogger` parameter to most JSON-generating functions.
Each function can update the given `ProgressLogger` between 0% and 100%, and create sub-loggers when calling functions.
The main goal of this instrumentation is to notice when any progress is made by child processes (when the parent process is gathering profiles), so it needs to go deep enough so that it is not stuck on a progress value for "too long" -- During development, that meant progress was always happening when observed every 10ms; In later patches, the overall timeout for no-progress-made will be at least 1 second.
Differential Revision: https://phabricator.services.mozilla.com/D135479
Class storing a value between 0 and 1, effectively 0% to 100%.
It will be used through a ProgressLogger object to track the progress of JSON profile generation (see following patches).
Differential Revision: https://phabricator.services.mozilla.com/D135477
Previously the process startup timestamp was computed lazily but this caused
some issues with some of our static analysis infra (see bug 1678152). This
moves computing the timestamp early during process startup and makes it happen
unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D136406
As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
Previously the process startup timestamp was computed lazily but this caused
some issues with some of our static analysis infra (see bug 1678152). This
moves computing the timestamp early during process startup and makes it happen
unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D136406
As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
* Define urlbarMarginInline and urlbarSearchButtonWidth as CSS rather than preprocessor variables
* Replace the urlbarViewPadding, urlbarViewFaviconWidth and urlbarViewIconMarginEnd preprocessor variables with CSS vars.
* Remove %ifdefs around the license comment in these 2 files
* Update ambiguous/out-of-date comment in the skeleton UI code
Differential Revision: https://phabricator.services.mozilla.com/D135962
* Define urlbarMarginInline and urlbarSearchButtonWidth as CSS rather than preprocessor variables
* Replace the urlbarViewPadding, urlbarViewFaviconWidth and urlbarViewIconMarginEnd preprocessor variables with CSS vars.
* Remove %ifdefs around the license comment in these 2 files
* Update ambiguous/out-of-date comment in the skeleton UI code
Differential Revision: https://phabricator.services.mozilla.com/D135962
Note: The atomic variable is named `gSkipSampling`, not mentioning forks because it could later be used in other situations, so it's best to describe it by the effect it has.
Differential Revision: https://phabricator.services.mozilla.com/D136205
`PrintUsageThenExit(code)` was supposed to exit when `code` was not zero, but:
- The name didn't reflect that, so it was confusing that `PrintUsageThenExit(0)` would *not* exit.
- The implementation in the Base Profiler exited anyway! This caused issues with some legacy code that still used the now-removed "threads" feature.
This patch renames the function to just `PrintUsage()` and never exits, leaving the caller to invoke `exit(code)` as needed -- with the added benefit that it's possible to exit with a zero code, useful in cases where an exit is not actually an error.
Differential Revision: https://phabricator.services.mozilla.com/D135666
I'm gonna guess there was no existing use of the tuple
serialization/deserialization code, because `Bytes` doesn't exist in the
deserializer, and cannot possibly function properly on tuple members that
serialize to a non-constant size, since it's called on a default-constructed
tuple.
This patch took inspiration in the deserializer for Variant and seems to work
fine.
Differential Revision: https://phabricator.services.mozilla.com/D135028
