Setting breakpad minimum log severity level to CRITICAL should be enough to
quiet it completely since there are no statements in the code using it, the
"highest" I could find all use the ERROR level.
Differential Revision: https://phabricator.services.mozilla.com/D70115
--HG--
extra : moz-landing-system : lando
On Windows content process minidump generation goes through the following
steps:
* The child process exception handler invokes the `filter` callback. This is the
`ChildFPEFilter()` function in nsExceptionHandler.cpp.
* If this callback returns true then the child process sends a request to the
crash generation server living in the main process and then waits.
* The main process generates a minidump in response to this message.
* Once the minidump has been generated the crash generation server calls the
`dump_callback` callback with the minidump filename. This is the
`OnChildProcessDumpRequested()` function in nsExceptionHandler.cpp.
* Once this callback returns the main process signals the child process that
it has finished generating the dump.
* The child process resumes execution in the exception handler and then
terminates.
During this process we send crash annotations via a pipe from the child
process to the main process. The function responsible for this is
`PrepareChildExceptionTimeAnnotations()` in nsExceptionHandler.cpp and it's
called within `ChildFPEFilter()`. Because pipe writes are blocking if we send
enough annotations to fill the pipe buffer then the child process will get
stuck in `ChildFPEFilter()` and never request a dump from the main process. Thus
the content process will never shut down and the main process will never see
that it has crashed, it will only appear indefinitely stuck.
To solve this issue a few changes are necessary:
* The crash annotations are not sent from the `filter` callback, they are sent
from the `minidump` callback which we did not use before. This callback is
executed in the child process **after** signaling the main process.
* This is not enough to prevent the deadlock though, because the content
process will still wait before the parent process has responded before
invoking this new callback. The parent process on the other hand will
generate the minidump and then call `OnChildProcessDumpRequest()` which will
wait to read the annotations sent by the child process. Thus both processes
would be stuck. To solve this other issue we change the order in which the
parent process responds: instead of invoking the `dump_callback` first and
then signaling the child process it does the opposite.
I've also added a new test that covers two separate issues solved by this
patch-set: that we don't deadlock when writing too much data (this issue) and
that we don't fail to send an annotation if it's too large (previously the
shared memory buffer was 16KiB in size so this annotation wouldn't fit).
Differential Revision: https://phabricator.services.mozilla.com/D69877
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
We previously only included the contents of the /etc/lsb-release file, however
this file is not present in RedHat-based distributions which use
/etc/os-release instead. This patch will read the latter if the former is not
present.
Differential Revision: https://phabricator.services.mozilla.com/D68986
--HG--
extra : moz-landing-system : lando
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--HG--
extra : moz-landing-system : lando
Each allocation page is now bracketed by a guard page, and allocations are put
at the end of their page so that bounds violations trigger a crash.
Various operations (realloc(), free(), malloc_usable_size()) now require that
the pointer they are given points to the start of an allocation.
Differential Revision: https://phabricator.services.mozilla.com/D43842
--HG--
rename : toolkit/crashreporter/test/unit_ipc/test_content_phc2.js => toolkit/crashreporter/test/unit_ipc/test_content_phc3.js
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
This includes several fixes required to build against musl libc.
Conflicts were resolved in 00-arm-exidx-rollup.patch and
10-json-upload.patch. 08-dont-add-sp-to-clobber-list.patch was
applied upstream and is no longer needed. The others applied cleanly.
breakpad_getcontext.S is now built conditionally based upon the
available of getcontext() from libc, rather than only on Android.
The profiler was updated to reflect this change.
Differential Revision: https://phabricator.services.mozilla.com/D67108
--HG--
rename : toolkit/crashreporter/breakpad-patches/09-gnu-alt-form-minimal-support.patch => toolkit/crashreporter/breakpad-patches/08-gnu-alt-form-minimal-support.patch
rename : toolkit/crashreporter/breakpad-patches/10-json-upload.patch => toolkit/crashreporter/breakpad-patches/09-json-upload.patch
rename : toolkit/crashreporter/google-breakpad/src/common/android/breakpad_getcontext.S => toolkit/crashreporter/google-breakpad/src/common/linux/breakpad_getcontext.S
rename : toolkit/crashreporter/google-breakpad/src/common/android/breakpad_getcontext_unittest.cc => toolkit/crashreporter/google-breakpad/src/common/linux/breakpad_getcontext_unittest.cc
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
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
The telemetry session ID annotation is only used to correlate crash pings with
main pings, it does not need to be sent along with crash reports as we have no
use for it there.
Differential Revision: https://phabricator.services.mozilla.com/D65446
--HG--
extra : moz-landing-system : lando
Windows programs run via Wine don't like Unix absolute paths (they look
like command line arguments), so we need to use relative paths.
Mingw already run fxc2 via wine, but for some reason it doesn't care
about the Unix absolute paths. genshaders does need some adjustements to
run properly with the real fxc.
Now, on actual Windows, because the temporary directory where
tempfile.NamedTemporaryFile creates files by default is not necessarily
on the same drive as where the command runs from, a relative path can't
be constructed. So we also force the temporary file to be created in the
current (obj) directory.
There is no similar concern for other files because we only go from
objdir to srcdir, and the build system already doesn't support both
being on a separate drive.
While here, flush stdout when the genshared script writes to it, so that
the messages are printed out immediately rather than randomly, later,
after output from subprocesses.
Differential Revision: https://phabricator.services.mozilla.com/D64294
--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
Gets rid of `NS_NewThread`. Where it was used in testing, I gave the new named threads names relevant to their tests.
Differential Revision: https://phabricator.services.mozilla.com/D62475
--HG--
extra : source : 541b98270c9985c5bd3569ff3ff8bc6c3d3c650a