Poison was setup at the start of xpcom init when that was assumed to be early enough.
Since then, Poison was added to Maybe, and Maybe has been used everywhere, including in
our channel implementation. As a result, poison was being used before it was initialized.
This basically meant our poison pointers were being replaced with null instead, which
dances into some more UB than accessing a page we have actually allocated. Also, tsan
noticed that accesses to the value were racing with the initializer actually being
called!
A (dynamic) static initializer forces the poison initialization as we can reasonably
hope without getting CallOnce or singleton patterns involved.
Other changes:
* Cleaned up the outdated documentation for mozWritePoison (the alignment
restriction was removed in Bug 1414901)
* Removed the poison supression from TSan
Differential Revision: https://phabricator.services.mozilla.com/D94251
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
We want to collect information on late writes via telemetry. We have been
doing this in Nightly for a while now, but want to do so in beta/release. I
was actually initially unaware of this limitation of the IOInterposer, but
we need the IOInterposer to collect information on late writes, so I would
like to enable it for just early beta, in the hopes that we can catch any
late writes that may be happening, without adding a performance tax onto
release.
Accordingly, is perf the only reason that this was restricted to Nightly?
And if so, did we measure a perf difference, or was this just general
caution regarding the performance impact? Is there anything else to look
out for?
Differential Revision: https://phabricator.services.mozilla.com/D90894
The RDD process gets shutdown following a NS_XPCOM_SHUTDOWN_OBSERVER_ID notification.
Notifications are processed in LIFO order, since the RDD process is started on demand it would have typically be registered after a content process.
We must ensure that the RDD get shutdown after all content processes so that it can receive notifications that the RemoteDecoderManagerChilds are shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D90485
The RDD process gets shutdown following a NS_XPCOM_SHUTDOWN_OBSERVER_ID notification.
Notifications are processed in LIFO order, since the RDD process is started on demand it would have typically be registered after a content process.
We must ensure that the RDD get shutdown after all content processes so that it can receive notifications that the RemoteDecoderManagerChilds are shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D90485
This backs out all work from bug 1627075 as well as all of its
descendents. There were a few conflicts when backing this out but
overall it was pretty clean, so I would say it's a fairly mild
level of risk. Historically Nathan Froyd has reviewed these patches,
but he is no longer at Mozilla, and no one else is particularly
familiar with the code, so I am passing this off to RyanVM who has
at least been familiar with the history of the bug.
Differential Revision: https://phabricator.services.mozilla.com/D90096
Mostly mechanical change, with some extra work where non-literal names are provided.
Also, when this is the only profiler call in a file, `#include "GeckoProfiler.h"` can be changed to `#include "mozilla/ProfilerMarkers.h"`.
Differential Revision: https://phabricator.services.mozilla.com/D89415
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
This is a speculative fix for a crash we're seeing due to xul.css ostensibly
not existing. The theory is that xul.css does in fact exist and the cached
zip central for the omnijar is simply corrupt in some way. If it is corrupt in
this way, then there is a bigger issue, and we need to investigate deeper.
However, the benefit of this approach is that it is a very small and contained
patch which should be simple to uplift.
Differential Revision: https://phabricator.services.mozilla.com/D86829
This changes the StartupCache::PutBuffer call from Omnijar to use a
fallibly allocated buffer, to reduce OOM crashes. We can/should broaden the
scope of this, but this is a simple initial change to mitigate the OOM
crashed introduced with bug 1627075.
Differential Revision: https://phabricator.services.mozilla.com/D86067
CLOSED TREE
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
We're crashing occasionally here due to an assertion in Span.h. We would
also likely have problems down the road if we tried to cache nullptrs in
the startup cache. I think this is all we need to handle this as gracefully
as we are able - at least, this should make it so the recent StartupCache
changes are no longer making failure any less graceful.
Differential Revision: https://phabricator.services.mozilla.com/D83189
If the original `NtCreateFile()` call failed, the file handle may have been left untouched, and is therefore probably uninitialized or in another unusable state.
Differential Revision: https://phabricator.services.mozilla.com/D82647
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We need to be able to init StartupCache before the Omnijar in order to cache
all of the Omnijar contents we access. This patch implements that.
Depends on D77632
Differential Revision: https://phabricator.services.mozilla.com/D77633
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We need to be able to init StartupCache before the Omnijar in order to cache
all of the Omnijar contents we access. This patch implements that.
Depends on D77632
Differential Revision: https://phabricator.services.mozilla.com/D77633
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We need to be able to init StartupCache before the Omnijar in order to cache
all of the Omnijar contents we access. This patch implements that.
Depends on D77632
Differential Revision: https://phabricator.services.mozilla.com/D77633
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
Use `GetFileType(HANDLE)` on Windows.
Unlike `HandleToFilename`, `GetFileType` is fast enough that we don't need to use a `SmallArrayLRUCache` for it.
The pipe I/Os should not be visible anymore in the startup tests.
Differential Revision: https://phabricator.services.mozilla.com/D82303
Platform-specific observations will be able to specify a file type.
They will appear in distinct rows in the profiler.firefox.com Marker Chart.
The default type is "File", which is shown in markers as "FileIO" like before.
Differential Revision: https://phabricator.services.mozilla.com/D80399
Caching filenames in 32-entry LRU array covers >95% of calls, and makes the average `Filename()` call 5 to 10 times cheaper.
browser_start_content_mainthreadio.js needed to be updated to handle operations that now have a filename thanks to the cache.
Since `ClearPoisonIOInterposer()` is never called (see bug 1647107), during Firefox shutdown we put LRUCache in a shutdown mode, which bypasses the cache in case it is still used at that time.
Differential Revision: https://phabricator.services.mozilla.com/D79767
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We need to be able to init StartupCache before the Omnijar in order to cache
all of the Omnijar contents we access. This patch implements that.
Depends on D77632
Differential Revision: https://phabricator.services.mozilla.com/D77633
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We need to be able to init StartupCache before the Omnijar in order to cache
all of the Omnijar contents we access. This patch implements that.
Depends on D77632
Differential Revision: https://phabricator.services.mozilla.com/D77633
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
Caching filenames in 32-entry LRU array covers >95% of calls, and makes the average `Filename()` call 5 to 10 times cheaper.
browser_start_content_mainthreadio.js needed to be updated to handle operations that now have a filename thanks to the cache.
Differential Revision: https://phabricator.services.mozilla.com/D79767
After investigating the potential to reduce the nsTerminator's crash timeout from
1 min, to 20s, and then finally 40s, we have decided to this does not provide
significant gains to justify increasing the amount of shutdown hang crashes
and potential to lose data. We should maintain the crash timeout at 1 min.
Differential Revision: https://phabricator.services.mozilla.com/D77939
People seemed to be taking the comment as indicative that Services.py
wasn't providing everything they needed, so make it clearer that you can
still get `nsIXULAppInfo`, you just have to work a little harder.
Differential Revision: https://phabricator.services.mozilla.com/D77477
During the last cycle collection, state watchers may attempt to dispatch tasks to the current AbstractThread, so we can't clear the TLS entry until that step has completed.
We want the object to be deleted last; ordering in call to ClearOnShutdown() can't guarantee it.
Differential Revision: https://phabricator.services.mozilla.com/D75498
In practice this shouldn't substantially change the behavior, but
it gets around being UB, and it shouldn't really cost us in terms
of performance. The alternative would be adding it to the TSAN
whitelist, which feels worse.
Differential Revision: https://phabricator.services.mozilla.com/D72015
CLOSED TREE
Backed out changeset 939611f65438 (bug 1630655)
Backed out changeset 2e05e81cc858 (bug 1630655)
Backed out changeset bfb074351550 (bug 1630655)
In practice this shouldn't substantially change the behavior, but
it gets around being UB, and it shouldn't really cost us in terms
of performance. The alternative would be adding it to the TSAN
whitelist, which feels worse.
Differential Revision: https://phabricator.services.mozilla.com/D72015
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
This is being added to facilitate moving generation of the update URL to Rust (Bug 1567286). Once that has been completed, we should be able to remove the update URL from its current location in firefox.js so that it is not being duplicated in application.ini.
Differential Revision: https://phabricator.services.mozilla.com/D43300
--HG--
extra : moz-landing-system : lando
This works on all platforms with the exception of Linux where we remove the
exception handler only if the sandbox is disabled. With the sandbox enabled we
would have to whitelist sigaltstack() which breakpad uses to remove the
alternate signal stack which is not worth the fuss.
Besides this patch refactors the code that sets and unsets the exception
handler, cutting down on the duplication:
* The XRE_UnsetRemoteExceptionHandler() call is removed from XULAppAPI.h since it
was no longer used
* The duplicate checks for the special strings used to disable the remote exception
handler have been removed from CrashReporter::UnsetRemoteExceptionHandler()
leaving them in the calling code
* The SetRemoteExceptionHandler() function was consolidated into only one
piece of code with only one non-platform-specific shared prototype
* Some additional code was factored out to improve the readability
These changes pave the way both for bug 1614933 and for the oxidation of the
exception handler code.
Differential Revision: https://phabricator.services.mozilla.com/D67213
--HG--
extra : moz-landing-system : lando
This is already done for the outer nsJAR, but it wasn't done for the inner nsJAR.
(The omnijar is a nested zip archive on Android: the outer archive is the APK and the inner is the omnijar file.)
So we were re-using the file mapping but not the result of the uncompression.
Differential Revision: https://phabricator.services.mozilla.com/D63970
--HG--
extra : moz-landing-system : lando
This moves the late write checking forward to before xpcom-shutdown-threads
in Nightly, and it turns it on for after the last cycle collection on
beta/release.
Differential Revision: https://phabricator.services.mozilla.com/D63215
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
Since we've decoupled the writing of the StartupCache from the freeing
of the StartupCache's tables (which takes nontrivial time), this patch
moves the StartupCache's destructor later in shutdown so it will be
skipped in the early _exit(0) efforts. There is a remaining
WaitOnWriteThread in the StartupCache's destructor, but this is a
minor sanity check to avoid use-after-frees in the write thread during
shutdown. In general it won't matter as we already wait for the write
thread in the xpcom-shutdown observer, and if we shut down during write,
the system is set up to be okay with that (because it already happens).
Differential Revision: https://phabricator.services.mozilla.com/D62295
--HG--
extra : source : d79f1d283acde1a971fe0e5e6f1a8db075f8589a
extra : histedit_source : 32a2b4fec1fcf35960155b0f4280a38bcb54ec19
Since we've decoupled the writing of the StartupCache from the freeing
of the StartupCache's tables (which takes nontrivial time), this patch
moves the StartupCache's destructor later in shutdown so it will be
skipped in the early _exit(0) efforts. There is a remaining
WaitOnWriteThread in the StartupCache's destructor, but this is a
minor sanity check to avoid use-after-frees in the write thread during
shutdown. In general it won't matter as we already wait for the write
thread in the xpcom-shutdown observer, and if we shut down during write,
the system is set up to be okay with that (because it already happens).
Differential Revision: https://phabricator.services.mozilla.com/D62295
--HG--
extra : moz-landing-system : lando
Since we've decoupled the writing of the StartupCache from the freeing
of the StartupCache's tables (which takes nontrivial time), this patch
moves the StartupCache's destructor later in shutdown so it will be
skipped in the early _exit(0) efforts. There is a remaining
WaitOnWriteThread in the StartupCache's destructor, but this is a
minor sanity check to avoid use-after-frees in the write thread during
shutdown. In general it won't matter as we already wait for the write
thread in the xpcom-shutdown observer, and if we shut down during write,
the system is set up to be okay with that (because it already happens).
Depends on D62294
Differential Revision: https://phabricator.services.mozilla.com/D62295
--HG--
extra : moz-landing-system : lando
Every day clang's warnings continue to amaze me. As does our ability to trigger them.
I'm assuming that this line was meant to go within the scope of the `if`, because if it were outside the scope, then we'd be duplicating the previous `fprintf`.
Differential Revision: https://phabricator.services.mozilla.com/D61835
--HG--
extra : moz-landing-system : lando
I originally had this as a few patches, but the work to fix test
failures and get the whole thing into a complete working state
quickly tangled them up. Apologies for that. To summarize what's
going on here, however:
- We introduce two prefs: shutdown.fastShutdownStage and
shutdown.lateWriteChecksStage. The latter pref is set to 1, which
will leave the existing late write checking behavior unchanged.
However, we introduce this pref to make it simpler in the future
to bump the late write checks window earlier in the shutdown cycle.
- We introduce an AppShutdown class, which will house static methods
and a small amount of state for unifying some shutdown logic. Most
importantly, it will now manage the state for app initiated restarts,
as well as the logic for performing a safe fast shutdown.
- We refactored the existing restart code to call into the new
AppShutdown file, so that if we are configured to actually perform
a fast shutdown, we will be able to run the necessary restart logic
immediately before doing so. Previously, the restart logic occurred
later in the shutdown cycle than our late write checking, meaning
if we were to simply exit the process at that point in time, we
would never run the restart coe.
- Lastly, we updated two locations which called TerminateProcess and/or
_exit(0) to call into the AppShutdown method (DoFastShutdown).
Differential Revision: https://phabricator.services.mozilla.com/D59196
--HG--
extra : moz-landing-system : lando
nsIMutable is used only by DOM Blob/File. But Blobs are immutable by spec.
FileBlobImpl has a couple of lazy member values, but those are called when
the object is cloned in order to be sent to a different thread/process.
Differential Revision: https://phabricator.services.mozilla.com/D58946
--HG--
extra : moz-landing-system : lando
nsIMutable is used only by DOM Blob/File. But Blobs are immutable by spec.
FileBlobImpl has a couple of lazy member values, but those are called when
the object is cloned in order to be sent to a different thread/process.
Differential Revision: https://phabricator.services.mozilla.com/D58716
--HG--
extra : moz-landing-system : lando
This converts straightforward `nsAutoPtr` usage over to `UniquePtr`.
`nsClassHashtable` is left alone for now as that will have a larger impact.
`nsThread` is left alone for now as it has non-trivial ownership concepts.
Differential Revision: https://phabricator.services.mozilla.com/D58284
--HG--
extra : moz-landing-system : lando
This removes various unused `#include "nsAutoPtr.h"` in `xpcom/`. Additionally
adds a few includes to the media stack.
Differential Revision: https://phabricator.services.mozilla.com/D58282
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
This patch make changes of Gecko infrastrutures to run a fork server
process.
- ForkServerLauncher is a component, which creates a fork server
process at XPCOM startup.
- nsBrowserApp.cpp and related files have been chagned to start a
fork server in a process.
- Logging and nsTraceRefcnt were changed to make it work with the
fork server.
Depends on D46883
Differential Revision: https://phabricator.services.mozilla.com/D46884
--HG--
extra : moz-landing-system : lando
This patch make changes of Gecko infrastrutures to run a fork server
process.
- ForkServerLauncher is a component, which creates a fork server
process at XPCOM startup.
- nsBrowserApp.cpp and related files have been chagned to start a
fork server in a process.
- Logging and nsTraceRefcnt were changed to make it work with the
fork server.
Depends on D46883
Differential Revision: https://phabricator.services.mozilla.com/D46884
--HG--
extra : moz-landing-system : lando
I also removed the unused forward declaration of GMPLoader. It used to
be needed for the declaration of XRE_InitChildProcess.
Differential Revision: https://phabricator.services.mozilla.com/D54819
--HG--
extra : moz-landing-system : lando
This function works on all GeckoProcessTypes, not just those for child
processes.
Differential Revision: https://phabricator.services.mozilla.com/D54375
--HG--
extra : moz-landing-system : lando
This function works on all GeckoProcessTypes, not just those for child
processes.
Differential Revision: https://phabricator.services.mozilla.com/D54375
--HG--
extra : moz-landing-system : lando
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
This change makes it possible to access the remote agent service
from C++ and Rust.
Differential Revision: https://phabricator.services.mozilla.com/D50288
--HG--
extra : moz-landing-system : lando
This change makes it possible to access the remote agent service
from C++ and Rust.
Differential Revision: https://phabricator.services.mozilla.com/D50288
--HG--
extra : moz-landing-system : lando
Some kinds of leaks prevent NSS to not shut down properly, and right
now if that happens we crash. This interferes with our existing leak
checking code, so in this patch I make it not crash if we are already
leak checking. The failure is reported as a fake leak, so the test
should still fail when testing.
Differential Revision: https://phabricator.services.mozilla.com/D52914
--HG--
extra : moz-landing-system : lando
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
This was disabled in Bug 1441558 because it broke the mingw-gcc build.
But it doesn't break the mingw-clang build, and we don't support mingw-gcc
anymore, so we can re-enable it.
Differential Revision: https://phabricator.services.mozilla.com/D48645
--HG--
extra : moz-landing-system : lando
This changes the way crash reports for child processes happening too early
during the child process' startup. Before bug 1547698 we wrote a partial
.extra file with those crashes that lacked the process type. The user would
not be notified of those crashes until she restarted Firefox and even when
submitted those crashes would be erroneously labeled as browser crashes.
After bug 1547698 we stopped writing .extra files entirely for those crashes
which left orphaned .dmp files among the pending crash reports.
This patch does three things to improve the situation:
* It writes a partial .extra file so that the crashes are detected at the next
startup. So the user is still not notified directly of these crashes but she
can report them later.
* It adds the process type to the .extra file so that the crash reporters are
labelled correctly.
* It fixes a leak in the `pidToMinidump` hash-map. Since the crashes were
not finalized the `ChildProcessData` strucutre associated with them would
never be fred.
Differential Revision: https://phabricator.services.mozilla.com/D40810
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
In particular, on Windows stdin/out/err may not be associated with a stream
(e.g., app without console window), in which case _get_osfhandle() returns -2.
Differential Revision: https://phabricator.services.mozilla.com/D34513
--HG--
extra : moz-landing-system : lando
This removes the XRE_TakeMinidumpForChild() which does not need to be
exposed anymore in the XUL API as well as
IToplevelProtocol::TakeMinidump() which was simply unused.
Differential Revision: https://phabricator.services.mozilla.com/D31062
--HG--
extra : moz-landing-system : lando
This patch introduces an asynchronous XPCOM interface for the bits client added in Bug 1523417
Differential Revision: https://phabricator.services.mozilla.com/D25161
--HG--
extra : moz-landing-system : lando
Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : histedit_source : acdfd2357fd06551dff5286c6b7c56bd92dd347b
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : moz-landing-system : lando
The definitions can't be entirely removed yet because NSS still needs them.
Differential Revision: https://phabricator.services.mozilla.com/D23454
--HG--
extra : moz-landing-system : lando
NS_InitXPCOM() is currently not called in Gecko. It has been a one-line wrapper around NS_InitXPCOM2() since the year 2000 (bug 46320), presumably to maintain ABI compatibility for third-party users of XPCOM. We no longer need to worry about XPCOM ABI compatibility.
https://searchfox.org/mozilla-central/commit/cddb62593d786e0ff12b25037c74b01cb1a802e5
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
xpcom/build/XPCOMInit.cpp:187:1 [-Wmissing-prototypes] no previous prototype for function 'NS_InitXPCOM'
Differential Revision: https://phabricator.services.mozilla.com/D23266
--HG--
extra : rebase_source : 0ad5580e2978a8d5141bd6a9623c5af7359c78ca
extra : source : a9e4205868dbb847c01980051a56e99ad24a8ac1
If we are running a background thread in the launcher process to log failures,
then allowing the main thread to proceed with monkeypatching system calls is a
Bad Idea. This patch gives us an environment variable that, when set, indicates
that it is unsafe for PoisonIOInterposer to run.
This scenario is an uncommon one, but one that we must account for nonetheless.
Differential Revision: https://phabricator.services.mozilla.com/D21607
--HG--
extra : moz-landing-system : lando
Simon Giesecke
Bryce Seager van Dyk
Alexis Beingessner
Ricky Stewart
Bogdan Tara
Dorel Luca
Doug Thayer
Jean-Yves Avenard
Brindusan Cristian
Nika Layzell
Gerald Squelart
Gijs Kruitbosch
Nathan Froyd
Sylvestre Ledru
Mihai Alexandru Michis
Mike Hommey
Kris Maglione
Csoregi Natalia
Narcis Beleuzu
Noemi Erli
Butkovits Atila
Nicholas Nethercote
Emma Malysz
Bas Schouten
Dan Minor
Kershaw Chang
Bob Owen
Bobby Holley
Peter Van der Beken
Marco Bonardo
Razvan Maries
Andreas Farre
Kirk Steuber
Dzmitry Malyshau
Gabriele Svelto
Markus Stange
Mike Shal
Cosmin Sabou
shindli
David Major
Andrea Marchesini
Eric Rahm
Thinker Li
Andrew McCreight
Coroiu Cristina
Jan de Mooij
Andreas Tolfsen
Aaron Klotz
Daniel Varga
Randell Jesup
Martin Stransky
Ehsan Akhgari
Andreea Pavel
Tom Ritter
Emilio Cobos Álvarez
Gurzau Raul
Tarek Ziadé
Oana Pop Rus
Matt Woodrow
Myk Melez
Michael Froman
Daosheng Mu
Boris Zbarsky
Mark Goodwin
Chris Peterson
Chris Pearce
Florian Quèze
Ryan Hunt
Honza Bambas