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
