This was previously r=jchen and landed, but was backed out because some
Android tests were running on an unrealistically old Linux kernel. These
tests have been retired, so this can reland.
Differential Revision: https://phabricator.services.mozilla.com/D81278
Bug 1486524 disabled the features from the custom linker that required
AutoObjectMapperFaultyLib. We can now rely on AutoObjectMapperPOSIX
instead.
Differential Revision: https://phabricator.services.mozilla.com/D81264
The Base Profiler is still recent and barely used, so it may contain some bugs.
With bug 1586939, the Base Profiler is now used more often because it is controlled the same way as the Gecko Profiler.
This has surfaced some intermittent issues, which pollute existing tests.
Until the root cause is found (see bug 1648325), setting `MOZ_PROFILER_STARTUP_NO_BASE=1` prevents the Base Profiler from running. This may be used where problems are visible, to diagnostic them and/or reduce them where needed.
Differential Revision: https://phabricator.services.mozilla.com/D81018
To avoid deadlocks between the profiler mutex and another mutex that may be locked when an allocation is intercepted, we now abort this interception if the profiler mutex is already locked.
Differential Revision: https://phabricator.services.mozilla.com/D79413
This function can be called whether the profiler mutex is locked or not. If locked, the provided pointer to the profiler mutex is used internally, otherwise the mutex will be locked as needed.
Differential Revision: https://phabricator.services.mozilla.com/D79412
PSAutoTryLock attempts to lock the mutex, but gives up immediately if it's already locked.
This can be used in profiler functions that may be called from unknown code, to avoid deadlocks involving the profiler mutex and another mutex that could be indirectly used by the profiler itself.
Differential Revision: https://phabricator.services.mozilla.com/D79410
There is some remaining code in central originating from bug 1184405, which sought to associate source files with their "affected" test files. That ended up not panning out, and bug 1644228 removed a lot of that code, but left some remnants in the `Files` object which are still referenced in a couple different places. I'm deleting all of that code in `context.py` plus everything that references it for the following reasons:
1. Right now, `Files.{test_files,test_tags,test_flavors}` do get populated, but only ever with "default" values -- namely `moz.build` files that are above the files in question in the directory hierarchy. This is a heuristic that doesn't actually have anything to do with mapping source files to their corresponding test files, which is misleading.
2. Those attributes are accessed in two places. The first is in the `mach file-info dep-tests` command. This command isn't referenced anywhere else in tree and I don't have any evidence anyone ever uses it. Even if they do, I would claim that doing so is a mistake (because the results of the command aren't meaningful and are just populated by the "defaults" described above), and that person's workflow should be migrated to something else that *is* meaningful.
3. The second place where this metadata is accessed is in `testing/mozbase/moztest/moztest/resolve.py`; that method is invoked in `tools/tryselect/selectors/syntax.py`, but only if you pass `--detect-paths` to `mach try syntax`. This is [entirely broken](https://bugzilla.mozilla.org/show_bug.cgi?id=1614614), and even if we made an effort to fix it, it wouldn't do anything resembling what the documentation of `--detect-paths` suggests it would do (again, because the data isn't populated meaningfully). So I'm deleting the command line option entirely.
Differential Revision: https://phabricator.services.mozilla.com/D79711
The version check is done above. So, it will fail there.
Move the binary check earlier to have a better error message
+ simplify the code
Differential Revision: https://phabricator.services.mozilla.com/D79725
Note that I cannot do unit test because of it doesn't support regex payload
''Failed: could not resolve a lint function from''
Differential Revision: https://phabricator.services.mozilla.com/D78158
In the JIT frame sampler, we apply the appropriate category in addition to
the "implementation" field. For JS frames (IS_JS_FRAME), we identify as
either BaselineInterpreter or Interpreter. Note that JS_Other still applies
to various places we enter SpiderMonkey outside of RunScript.
Differential Revision: https://phabricator.services.mozilla.com/D79524
Replace the duplicate lists in mozglue/baseprofiler/public and js/public with
a shared list. Add this list to both moz.build files so it is published twice
which simplifies supporting different standalone configurations.
Differential Revision: https://phabricator.services.mozilla.com/D79520
Introduce an IS_BLINTERP_FRAME flag to ProfilingStackFrame to distinguish C++
and Baseline interpreter frames. In the profile data this sets the
"implementation" to "blinterp".
Differential Revision: https://phabricator.services.mozilla.com/D78725
Now we are pausing the profiler just before capturing the profile data. Android
sampler will never be running when this code is being run
Depends on D78037
Differential Revision: https://phabricator.services.mozilla.com/D78038
This patch adds a small README file to the tools/browsertime folder to give people more information about its purpose and provides a link to the perftest wiki.
Depends on D78044
Differential Revision: https://phabricator.services.mozilla.com/D78045
When python2 interprets headers here, it will attempt to encode values into a string in a blanket fashion.
In this case, the `Accept` header is encoded into an invalid value, but it "works".
Python3 validates more strictly, and throws an error when an array is encountered as a value here. Formatting it
as a valid string instead resolves the problem.
Differential Revision: https://phabricator.services.mozilla.com/D77735
With the addition of this change, a lone `mach busted file` will throw an error (since this should only ever be used by actual humans, and not in automation or anything, the backwards-compatibility breakage isn't a huge deal). Now it's expected to pass in `mach busted file $COMMAND`, where $COMMAND is the mach command that you were running when the error occurred, and we'll figure out which bugzilla component to file the bug against for you instead of directing it to `Firefox Build System :: General` regardless of whether the issue has *anything* to do with the build system. We preserve `mach busted file general` as a backup command that doesn't do any of this heavy logic.
Differential Revision: https://phabricator.services.mozilla.com/D77538
`|mach lint -f treeherder|` expects lint to not fail ever, if a lint fails it's
just ignored. This means that when our javadoc errors out and fails the build
all lints are ignored.
To avoid that we add `failOnError = false` to the javadoc job so that we can
finish the build and actually report the errors.
This patch also adds gradle output `|mach lint|` to make it easier to
diagnose errors in the lint.
Differential Revision: https://phabricator.services.mozilla.com/D77373
`|mach lint -f treeherder|` expects lints to not fail ever, if a lint fails it's
just ignored. This means that when our javadoc errors out and fails the build
all lints are ignored.
To avoid that we add `failOnError = false` to the javadoc job so that we can
finish the build and actually report the errors.
This patch also adds gradle output `|mach lint|` to make it easier to
diagnose errors in the lint.
Differential Revision: https://phabricator.services.mozilla.com/D77373
nsTHashtable::Remove doesn't assert if the item isn't present. Match that
behavior by removing the assert and putting it at all of the call sites.
This just turns IDMap::Remove into RemoveIfPresent, so merge them.
Differential Revision: https://phabricator.services.mozilla.com/D77166
This function is similar to the Put() method in nsTHashtable, but it lists the
key second and it asserts that the key is not already in the map. This patch
swaps the arguments and hoists the assertion out, where appropriate. Note that
there are a few places that were working around this assert, so for those places
don't include the assert.
Differential Revision: https://phabricator.services.mozilla.com/D77165
Now both profilers are controlled by the same environment variables, e.g.
"MOZ_PROFILER_STARTUP" to run both profilers at startup.
The only remaining Base Profiler-specific commands are:
- MOZ_BASE_PROFILER_HELP, because the Base Profiler doesn't have the same
capabilities as Gecko, so it may display different available features.
- MOZ_BASE_PROFILER_LOGGING, because the Base Profiler doesn't have access to
MOZ_LOG (both the env-var and the C++ macros).
Differential Revision: https://phabricator.services.mozilla.com/D54449
Now both profilers are controlled by the same environment variables, e.g.
"MOZ_PROFILER_STARTUP" to run both profilers at startup.
The only remaining Base Profiler-specific commands are:
- MOZ_BASE_PROFILER_HELP, because the Base Profiler doesn't have the same
capabilities as Gecko, so it may display different available features.
- MOZ_BASE_PROFILER_LOGGING, because the Base Profiler doesn't have access to
MOZ_LOG (both the env-var and the C++ macros).
Differential Revision: https://phabricator.services.mozilla.com/D54449
Hopefully this will avoid some intermittent failures that occur when
`fix-stacks` is deleted at the end of a test run.
Differential Revision: https://phabricator.services.mozilla.com/D76980
If EAF+ is enabled for firefox.exe, the process does not launch because we parse
the PE headers of ntdll.dll at startup, which is prohibited by EAF+.
With this patch, we skip two operations when EAF+ is enabled.
The first one is to cache ntdll's IAT at startup. Because EAF+ is expected to
prevent an injected module from parsing PE headers and modifying IAT, we can skip
this caching safely.
The second one is to load ntdll's debug information for the profiler. With this
patch, the profiler's callstack will not show a raw address instead of a symbol
name. It's a bad side effect, but much better than startup crash.
Differential Revision: https://phabricator.services.mozilla.com/D76959
This is the logic of tracing the WebGPU API calls at the level of wgpu-core,
serialized into a folder of choosing on the user drive. Traces are extremely portable,
they can be shared (on BugZilla) and then replayed on the developer machine,
which can have a different architecture from the users machine.
The standalone player is introduced in `gfx/wgpu/player`, similar to WebRender's Wrench.
The output dir is controlled by "dom.webgpu.traceDir" pref. No tracing happens if it's empty.
Differential Revision: https://phabricator.services.mozilla.com/D73333