Puppeteer happens to send huge payloads as part of their test suite when using their $$eval API.
This is because they pass back and forth nodeLists for which all children are serialized by default.
This could be avoided by changing the serialization options (see https://github.com/puppeteer/puppeteer/issues/10582)
But without such a fix, we need to cap the size of the websocket logs, otherwise the logparser is unable to handle the
logs from the bidi puppeteer job.
Differential Revision: https://phabricator.services.mozilla.com/D184108
In mozilla::freestanding::patched_NtMapViewOfSection, the DLL blocklist
code relies on implicit assumptions about how LoadLibrary(Ex)W and
Thread32Next work internally.
Some of these assumptions turned out to be false on Windows 7. This led
to crash spikes with 115 release; first in bug 1837242, and then later
in bug 1842368. After dealing with the crash spikes, we realized that
some blocklist gtests are still failing on Windows 7, due to such wrong
assumptions. So, in bug 1842088, we are changing the assumptions.
This patch adds a dedicated cppunit test to test these assumptions in
isolation. It is easier to run than blocklist gtests, and should lead to
easier diagnostics in case the assumptions break in the future. This
test also checks the Thread32Next assumptions, which protect us against
the crash from bug 1733532.
Depends on D183530
Differential Revision: https://phabricator.services.mozilla.com/D183757
Our blocklist code must allow loading blocked modules using
LoadLibraryExW with LOAD_LIBRARY_AS_IMAGE_RESOURCE, so that we can
collect information about them when we want to send untrusted module
pings. This means that we need a trustworthy way to distinguish between
these loads and regular DLL loads.
Currently, we do the distinction by looking at the AllocationProtect
field for the virtual memory mapped for the view. This solution was
introduced with bug 1702717, but unfortunately it doesn't work with
Windows 7. This - mixed with other reasons - has resulted in the crash
spike in bug 1842368.
We should thus move to a more trustworthy solution to distinguish
between these two kinds of DLL loads. The new solution is to instead
check whether the permission to map executable views was asked when the
section that we are mapping was created. Because this solution is past
proof, it also has more chances to be future proof.
Differential Revision: https://phabricator.services.mozilla.com/D183530
Now that we have upgraded to a version of rustc that uses LLVM 16, it
can read profile data from LLVM 16, so we don't need to artificially
make the profile data look like LLVM 15's anymore.
Differential Revision: https://phabricator.services.mozilla.com/D184413
Note that rect() computes to the equivalent inset() function as well.
i.e. Given `rect(t r b l)`, the equivalent function is
`inset(t calc(100% - r) calc(100% - b) l)`.
The implementation is straightforward, and we don't have to change
anything in cpp because it is always `inset()` when building the gfx::Path.
The tests for clip-path will be added in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D183528
Now that we selectively load command modules, and activate the command
virtualenv much earlier in the mach process, a lot of the module
dependencies specified in `mach.txt` are no longer necessary there. With
their removal from `mach.txt` they will no longer be automatically
inherited by every site, which reduces potential dependency conflicts
for specific sites.
The `common` site still effectively has the same set of dependencies.
This is the default site that all commands use unless otherwise
specified. Most commands use this site, and going through every command
and seeing if a dependency is or isn't needed, then deciding if or if
not to create a new site for that command made sense was too time
consuming to do here.
Essentially the idea here going forward is that if you're trying to
add/update a new dependency to a command that is currently defaulting to
the `common` site and there is a conflict with one of the dependencies
in `common` you can move your command to a new site specifically for
your command, and you will have the minimal possible set of dependencies
a mach command can have, improving the odds that you can add the
module(s) you need for your command.
Depends on D180500
Differential Revision: https://phabricator.services.mozilla.com/D180501
This is really just shuffling a bunch of things around. None of the
'load_*' member functions of the `Mach` class actually needed to be
member functions. They can all be static so that they can be used
anywhere. That combined with moving all the other 'mach_command' logic
to a different file, allows us to load the module for any command so
that we can successfully dispatch it.
Differential Revision: https://phabricator.services.mozilla.com/D184060
This makes loading almost all commands faster, since only one module
file is loaded rather than all of them. There is one main exception,
dealing with 'help'. Running `./mach help` (or -h or --help) requires
the description text for every command, so every module file is still
loaded.
We could expand this improvement here to consolidate all commands and
their parameters in this `MACH_COMMANDS` dict, but the only two benefits
are improving help, and not having two places where the commands are
specified (their file, and this dict).
There's a lot of extra work needed to do that, especially for handling
sub commands, and it did not seem worth the cost for the benefit at this
time.
Depends on D180499
Differential Revision: https://phabricator.services.mozilla.com/D180500
This activated virtualenv for a command is managed
`CommandSiteManager` and it is passed down to where it was activated
before to prevent a second, redundant, activation.
Differential Revision: https://phabricator.services.mozilla.com/D180499
We started using this extension as an optimization on Adreno GPUs in
bug 1828248. At the time, we discovered that there was a driver bug in
version 0490 of the Adreno driver resulting in rendering errors on a
variety of Adreno GPUs. We therefore blocked the usage of the
extension on that driver version.
We have now discovered another bug causing even more apparent
rendering issues. This appears to only affect Adreno 308 GPUs running
driver versions 331 or 415. This patch therefore additionally blocks
the extension on such devices.
Differential Revision: https://phabricator.services.mozilla.com/D184388
