Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses.
Differential Revision: https://phabricator.services.mozilla.com/D103730
ProfileBufferCollector::SamplePositionInBuffer() and BufferRangeStart() need to provide indices in the same main buffer, because they will be used to discard old data (at some previous `SamplePositionInBuffer`) once the `BufferRangeStart` indicates that it is not referenced by the profiler anymore.
Because the periodic sampler uses a local buffer (to avoid allocations and locks), we need to record the special location from the main profiler buffer in ProfileBufferCollector.
Differential Revision: https://phabricator.services.mozilla.com/D104497
This avoids paying a cost for animating the skeleton UI for faster startups.
Slow startups don't seem to be affected, given the data available. This is
likely due to slow startups being dominated by IO.
Differential Revision: https://phabricator.services.mozilla.com/D104118
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
The standard for printf says that for integers, the result of converting
zero with an explicit precision of zero shall be no characters. But
flags and width still need to apply.
Differential Revision: https://phabricator.services.mozilla.com/D102696
%F and %G are the same as %f and %g, but using caps for the exponent
indicator, and for "inf"/"nan" for infinity and NaN.
%n$E is the same as %E, but taking the nth argument.
Differential Revision: https://phabricator.services.mozilla.com/D102695
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
The standard for printf says that for integers, the result of converting
zero with an explicit precision of zero shall be no characters. But
flags and width still need to apply.
Differential Revision: https://phabricator.services.mozilla.com/D102696
%F and %G are the same as %f and %g, but using caps for the exponent
indicator, and for "inf"/"nan" for infinity and NaN.
%n$E is the same as %E, but taking the nth argument.
Differential Revision: https://phabricator.services.mozilla.com/D102695
This will disable the skeleton UI if we crash while setting it up, and further
the error will propagate up and get reported via telemetry on the next run.
This is important because we don't have anything like the crash reporter set up
by the time we want to start showing the skeleton UI.
Differential Revision: https://phabricator.services.mozilla.com/D102355
This is, for the most part, just a large refactor of the skeleton UI stuff to
support coarse-grained error reporting via telemetry. There are a few slight
changes in how we handle some errors. For example, if CreateWindow fails, we
will now bail out and report the failure. The flow for the happy path, however,
should remain unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D102098
This patch displays the new telemetry field "loadStatus", which was introduced
by the earlier patch, on about:support. With this information, a user can see
each of injected modules was really loaded or blocked by our DLL blocklist.
Differential Revision: https://phabricator.services.mozilla.com/D102409
We used to record a DLL loading event only when a module was loaded.
With this patch, we record an event for a module blocked by our DLL
blocklist as well as a loaded module. It is achieved by calling
to `ModuleLoadFrame::NotifySectionMap` in `patched_NtMapViewOfSection`
regardless of the block action.
This patch introduces a new member `ModuleLoadInfo::mStatus` and
`ProcessedModuleLoadEvent::mLoadStatus` to keep the DLL loading status,
which will be added to the third-party-modules ping by a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D102407
This patch displays the new telemetry field "loadStatus", which was introduced
by the earlier patch, on about:support. With this information, a user can see
each of injected modules was really loaded or blocked by our DLL blocklist.
Differential Revision: https://phabricator.services.mozilla.com/D102409
We used to record a DLL loading event only when a module was loaded.
With this patch, we record an event for a module blocked by our DLL
blocklist as well as a loaded module. It is achieved by calling
to `ModuleLoadFrame::NotifySectionMap` in `patched_NtMapViewOfSection`
regardless of the block action.
This patch introduces a new member `ModuleLoadInfo::mStatus` and
`ProcessedModuleLoadEvent::mLoadStatus` to keep the DLL loading status,
which will be added to the third-party-modules ping by a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D102407
This is no longer going to be detected by tsan. I figure with full shutdown enabled we should be able to see if there were other issues around this one.
Differential Revision: https://phabricator.services.mozilla.com/D102487
Thunderbird does not yet have the same blocklist initialization as Firefox, so we skip calling InitDllBlocklistOOP to avoid a MOZ_RELEASE_ASSERT.
Differential Revision: https://phabricator.services.mozilla.com/D99173
This patch is to improve the way to detect an injected dependent module for
automatic DLL blocking (bug 1659438).
In the previous version, we created a list of dependent modules in the launcher
process and shared it with other processes via the shared section. However, it
was not compatible with third-party applications who tamper the Import Table and
revert it in the injected module's DllMain (bug 1682834) because we parsed the
Import Table in the launcher process after it was reverted.
With this patch, we check the Import Table in `patched_NtMapViewOfSection`,
so we can see tampering before it's reverted. More specifically, we create
a list of dependent modules in the browser process as below.
1. The launcher process creates a section object and initializes
the kernel32.dll's functions in it.
2. The launcher process transfers a writable handle of the shared
section to the browser process.
3. In the browser process, if an injected dependent module is being
mapped by `NtMapViewOfSection`, we add its NT path to the shared
section and block it with `REDIRECT_TO_NOOP_ENTRYPOINT`.
4. The `main` function of the browser process converts the writable
handle of the shared section into a readonly handle.
5. The browser process transfers a readonly handle of the shared
section to a sandbox process.
Since automatic DLL blocking may still cause a compat issue like bug 1682304,
we activate it only in Nightly for now.
Differential Revision: https://phabricator.services.mozilla.com/D101460
Currently, printf_stderr doesn't show up when running with ./mach run.
This is because we run with -attach-console and that redirects stderr
to a different file descriptor using freopen in UseParentConsole.
The change from just using stderr directly happened in bug 340443 and was done
to avoid some linking issues. That problem doesn't seem to apply anymore so you'd
expect we'd be able to go back to the straightforward implemention that works even
if stderr has been redirected. Unforunately, Windows takes not buffering
stderr very seriously and fprintf will write out the results character
by character. This can cause log output lines to be intermixed which
breaks log parsing in CI. We keep using fdopen to create a new FILE*
that's buffered but instead of hard coding fd 2, we get the actual fd
that corresponds to stderr using fileno.
The mozglue implementation was cargo culted from xpcom, so we update it
as well.
Differential Revision: https://phabricator.services.mozilla.com/D98550
CLOSED TREE
Backed out changeset f82f5070bee5 (bug 1205985)
Backed out changeset 89b03879ce7d (bug 1205985)
Backed out changeset 9ba60febbcf8 (bug 1205985)
This eliminates all of the thread leaks we had on record, while also increasing
our coverage on the code that's used for testing firefox.
Differential Revision: https://phabricator.services.mozilla.com/D100264
`ImageBridgeChild` was turned into a one-off thread due to a deadlock, but when bug 1672255 is finished we can revert the changes back to a background task queue without any issues and get rid of these suppressions.
Differential Revision: https://phabricator.services.mozilla.com/D100257
The `RunningTimes` class stores CPU measurements. It may seem overkill for only one value, but in the future more measurements will be added.
During sampling, CPU measurements are collected by platform-specific code. This patch doesn't produce anything yet, see later patches.
These are stored with the samples.
Note that for duplicated samples (when a thread is known to be "asleep"), we still need to collect new measurements, because there could potentially be some activity happening, e.g. in system calls.
Finally the measurements are output as extra "samples" values.
Units for these values may platform-specific, so they are stored in the top-level JSON "meta" object.
We don't collect running times in the Base Profiler (yet), but we still need to add the appropriate field names in the samples' "schema", as expected by profiler.firefox.com.
Differential Revision: https://phabricator.services.mozilla.com/D99413
This patch adds "CPU Utilization" ("cpu" for short) as a new feature that will control the upcoming still-experimental CPU measurements.
Differential Revision: https://phabricator.services.mozilla.com/D99054
Instead of only capturing one feature (NoStackSampling), the sampler thread now stores all features so that any feature can be quickly looked at during sampling.
Currently this is still limited to NoStackSampling, a later patch will start using another feature.
Differential Revision: https://phabricator.services.mozilla.com/D99053
Now is already supported when CLOCK_MONOTONIC is supported, but
ComputeProcessUptime is not. This shares the code with other BSDs, and
makes it look like the implementation in Timestamp_darwin.cpp.
Eventually, we'll remove the one from Timestamp_darwin.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D100069
Some sites do have stacks that require more than 64KB to store in the profiler buffer.
Note that this only affects one semi-permanent buffer per process during profiling, and short-lived buffers when capturing stacks in markers.
Differential Revision: https://phabricator.services.mozilla.com/D99981
The "expected maximum stack size" (currently 64KiB) value was present in multiple places.
Now it's accessible from everywhere as ProfileBufferChunkManager::scExpectedMaximumStackSize, so it's easier to modify as needed.
Differential Revision: https://phabricator.services.mozilla.com/D100222
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
In DEBUG builds, instead of only testing for the expected chunk state(s), there are now separate assertions for each *un*expected state, which makes it much easier to track the source of failures.
Differential Revision: https://phabricator.services.mozilla.com/D99974
So this is an ugly solution, but it was the best I could come up with. We do
not want to show the skeleton UI if we're going to show the profile manager,
and we *will* show the profile manager if StartWithLastProfile=0 is under
[General] in profiles.ini. Accordingly the only ways to do the correct thing
here are to try to mirror edits that firefox makes to the profiles.ini file
to the registry, or to simply read the profiles.ini file ourselves. There are
many ways that profiles.ini could get out of sync with the registry if we
tried to mirror its state there, so going straight to the source of truth
seemed the best option.
There is one case which is still not covered here: if there is no profile for
our install marked as Default=1, then we will show the profile manager. This
should only be possible if the user manually edits their profiles.ini file,
however, and then it should resolve itself after one run, so I don't consider
it a significant enough problem to jump through all the hoops we would need
to jump through to solve it.
Depends on D98525
Differential Revision: https://phabricator.services.mozilla.com/D98936
Note that we can probably use mLastRefreshDriverTime directly in
DocumentTimeline::GetCurrentTimeStamp(), i.e. we don't need to use the refresh
driver there, but I'd preserve the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D97823
Note that we can probably use mLastRefreshDriverTime directly in
DocumentTimeline::GetCurrentTimeStamp(), i.e. we don't need to use the refresh
driver there, but I'd preserve the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D97823
Mihai Alexandru Michis
Mike Hommey
Markus Stange
Gerald Squelart
Alexis Beingessner
Doug Thayer
Florian Quèze
Yaron Tausky
smolnar
Csoregi Natalia
Toshihito Kikuchi
Kris Wright
Emma Malysz
Butkovits Atila
Greg Tatum
Geoff Lankow
Molly Howell
Razvan Maries
Brindusan Cristian
Paul Adenot
Jeff Muizelaar
Narcis Beleuzu
Masatoshi Kimura
Jon Coppeard
Hiroyuki Ikezoe
Andreea Pavel
Steve Fink