Bug 1620118 added a new field `isDependent` in the third-party-module ping
which is calculated in `UntrustedModulesProcessor`. However, bug 1684532
revealed it was not accurate because some third-party applications revert
the import table to the original state immediately after their module was
loaded.
Now that we have a logic to determine `isDependent` in `NtMapViewOfSection`
to automatically block a module injected through the import table, we can
pass that value to the ping and remove the original logic in `UntrustedModulesProcessor`.
Differential Revision: https://phabricator.services.mozilla.com/D112227
This patch makes sure the repo can be built without `MOZ_LAUNCHER_PROCESS`.
- Compile WinTokenUtils.cpp under winlaucher regardless of `MOZ_LAUNCHER_PROCESS`
because we still need `IsAdminWithoutUac`.
- Skip TestDllBlocklist.NoOpEntryPoint GTest because the `RedirectToNoOpEntryPoint`
feature is only available with the new blocklist with the launcher process.
Differential Revision: https://phabricator.services.mozilla.com/D108142
This makes mozilla::PrintfTarget consistent across all locales (not
printing e.g. "," instead of "." for the decimal point in floats in some
locales)
This implementation passes all the glibc tests in stdio-common/tfformat.c
except two tests because of the difference in how values like e.g 0.25 are
rounded. Printf in glibc and on MacOS, as well as Rust std::fmt, round to
nearest, ties to even. Double-conversion, as well as printf on Windows
and conversion functions in ECMAScript round to nearest, ties away from
zero.
The standard for printf says rounding is implementation-defined so
either way is technically correct.
Differential Revision: https://phabricator.services.mozilla.com/D102699
While at this point PrintfTarget doesn't use double-conversion, add a
test that it can (and thus will) handle the largest double output possible
with the default %f precision.
Differential Revision: https://phabricator.services.mozilla.com/D103431
It is worth noting that some of these tests fail on Windows for rounding
difference reasons (see later commit from this bug for more details),
and on both Windows and mac for differences in formatting for INFINITY
and NAN. All the tests pass on Linux (since the underlying printf is
currently glibc's).
Differential Revision: https://phabricator.services.mozilla.com/D103133
This makes mozilla::PrintfTarget consistent across all locales (not
printing e.g. "," instead of "." for the decimal point in floats in some
locales)
This implementation passes all the glibc tests in stdio-common/tfformat.c
except two tests because of the difference in how values like e.g 0.25 are
rounded. Printf in glibc and on MacOS, as well as Rust std::fmt, round to
nearest, ties to even. Double-conversion, as well as printf on Windows
and conversion functions in ECMAScript round to nearest, ties away from
zero.
The standard for printf says rounding is implementation-defined so
either way is technically correct.
Differential Revision: https://phabricator.services.mozilla.com/D102699
It is worth noting that some of these tests fail on Windows for rounding
difference reasons (see later commit from this bug for more details),
and on both Windows and mac for differences in formatting for INFINITY
and NAN. All the tests pass on Linux (since the underlying printf is
currently glibc's).
Differential Revision: https://phabricator.services.mozilla.com/D103133
Instead of discarding released chunks, we keep them as "next" chunks, and we make sure there's a valid "current" chunk when possible.
Recycling released chunks means that when using the `ProfileBufferChunkManagerSingle`, the one chunk, in whichever state it may be, will be kept alive and reused.
Differential Revision: https://phabricator.services.mozilla.com/D99979
When a "Put" operation fails (most probably because no chunk was available to store the data), we remember the number of bytes that couldn't be stored.
This can be useful to give an indication of how much more memory would have been needed for successful puts.
Differential Revision: https://phabricator.services.mozilla.com/D99977
This bug has revealed some issues when the single chunk gets filled, and there are different paths depending on whether the chunk is filled right to the end, or past it.
Later patches will fix these issues and update these tests accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D99976