Because the symbols server can only handle the .zip format for the
symbols archives, we make upload_symbols itself munge what it takes from
builds if they are .tar.zst, so that the symbols server is happy.
Eventually, the symbols server will be able to deal with those archives
on its own.
It is worth noting that this conversion is actually taking more time
than builds spend for the same archive because nothing is parallelized,
while in builds the compression of e.g. libxul.so and libxul-gtest
happen in parallel.
However, overall, we'll still gain from switching to this new code path
because builds currently always compress the debug info, even when it's
not going to be uploaded to the symbols server.
Differential Revision: https://phabricator.services.mozilla.com/D85250
This change surfaces errors faster, and ensures that we don't silently
end up with empty crashreporter symbols if `dump_syms` can't run for
some reason.
Differential Revision: https://phabricator.services.mozilla.com/D43520
The new `dump_syms` is smart enough to merge information gathered from the
dsymbundle and the primary file without any special calling out which is
which.
Depends on D84727
Differential Revision: https://phabricator.services.mozilla.com/D84728
If we don't do this, we run into problems when walking over the Mach-O load
commands, where we *do* mask off cpusubtype bits.
Differential Revision: https://phabricator.services.mozilla.com/D84356
nsIProcessToolsService::kill is designed to kill without causing crash reports.
Let's make sure it does not cause crash reports.
Differential Revision: https://phabricator.services.mozilla.com/D82553
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
This patch adds a vectored exception handler to catch STATUS_HEAP_CORRUPTION
exceptions on Windows. Previously these crashes would terimnate the affected
process without generating a minidump. For child process crashes the user would
be notified of the crash but could not report them. Main process crashes on the
other hand would close Firefox abruptly without any sort of feedback to the
user.
Note that this type of exceptions are originated from Windows default memory
allocator which we replace with jemalloc. As such they're unlikely to be thrown
from our code, but are frequently encountered when dealing with injected DLLs
and other external components.
Differential Revision: https://phabricator.services.mozilla.com/D83753
We originally added this functionality in bug 1566855 because we were
seeing a significant amount of orphaned crashes not being submitted.
Notably some of these were early content process startup crashes and
missing them made us unaware of severe issues that would affect our
users. In the meantime we've addressed most of the cases where a crash
would be orphaned. Since the crashes submitted this way have a buildid
that does not match the version of Firefox that actually crashed they
can be confusing during crash triage.
Given the above we can safely remove this functionality. This patch
reverts most of the changes from bug 1566855 but leaves the test
refactorings in place.
Differential Revision: https://phabricator.services.mozilla.com/D78219
In bug 1614933 we changed the order in which the crash annotations are sent
from a crashed content process to the main process in order to prevent a
deadlock that would arise if the child process would block writing into the
pipe used to sent the annotations.
This unfortunately introduced a race that I had missed. Here's the sequence of
event when generating a crash in the child process:
1) The child process enters the exception handler
2) It requests a dump from the main process and wait
3) Once the dump is written, the child process wakes up again and writes out
the crash annotations
4) The child process quits
One the main process side it looks like this:
1) The crash generation thread receives a request to generate a dump
2) The dump is written out, the crash generation thread notifies the content
process that it can resume execution. During this step the finished
minidump is recorded in the `OnChildProcessDumpRequested()` callback.
3) The crash generation thread reads the crash annotations sent by the content
process and finalizes the crash report
4) The main process grabs the finalized crash report
The key issue here is that the main process in step 4 is woken up when the
content process dies. Notice how there's no synchronization between the crash
generation thread and the main thread in the main process: if the crash
generation thread takes too long reading the crash annotations the main thread
might see an incomplete or missing crash report; that's because the event that
wakes it up - the content process ending execution - can happen in parallel
with step 3.
This is an issue that was accidentally introduced in Windows by bug 1614933
but was already present in both Linux and macOS. It was just very unlikely to
happen.
This patch fixes the issue by splitting step 3 in the main process in two
different stages: in the main process we grab the generated minidump in
`OnChildProcessDumpRequested()`, Breakpad then unblocks the child process and
we read the annotations in `OnChildProcessDumpWritten()`. We grab the
`dumpMapLock` Mutex in the latter and release it in the former to ensure that
the main process will have to wait for the crash report to be finalized when
`TakeCrashedChildProcess()` is called. This might appear somewhat confusing
and even causes debug builds to spit a harmless warning (we don't want Mutexes
to be taken and released from different scopes if we can help it).
To implement the above behavior in Breakpad a new callback was introduced in
Windows, an existing one was used under macOS and an unused one was used under
Linux. This accounts for the different way in which minidumps are generated on
the three platforms.
Differential Revision: https://phabricator.services.mozilla.com/D74496
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
This changes the way filter callbacks work in Breakpad so that the
Gecko-provided exception handler can instruct breakpad to just consider an
exception handled and terminate the process without further work. This change
is needed because when two threads enter the exception handler at the same
time the second can get stuck. The logic behind this is convoluted: when the
filter callback "accepts" an exception Breakpad will request minidump
generation and then notify Windows exception search mechanism that the
exception was handled. The process will terminate at this point. However if
a second thread enters the exception handler before this happens it will also
try to handle the exception, either by generating a minidump (prior to my fix
for bug 1434933) or by simply ignoring it (after bug 1434933). However under
both conditions Breakpad will consider the exception not handled and inform
Windows exception search logic to look for another handler. But we're already
at the top-level handler so Windows will try it again, and again, and again
... hanging the process instead of terminating it.
With this patch applied the first time we hit the exception handler we'll
request minidump generation and report the exception as handled. If we hit the
exception handler again we will not request minidump generation but we will
also report the exception as handled so that Windows can terminate the process
right away.
Differential Revision: https://phabricator.services.mozilla.com/D72493
This patch modifies exception handling in child processes so that no more than
one minidump will be requested in case of a crash - even when multiple threads
enter the exception handler almost simultaneously.
The fix is implemented by introducing an atomic flag that is set once we first
decide that the exception is a crashing one. All following threads entering
the exception handler will find the flag already set and give up.
This logic was added to the child process exception filters - callbacks that
breakpad invokes within the exception handler to decide whether to generate a
minidump or not. I factored out some of the affected code trying to make it a
bit more readable and a little bit less redundant than before.
Differential Revision: https://phabricator.services.mozilla.com/D71108
Made the files in toolkit/crashreporter flake8 compliant
And some finishing touches in the symbolstore.py file for readability
Differential Revision: https://phabricator.services.mozilla.com/D68691
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
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 : moz-landing-system : lando
This patch also exposes the desktop environment and window protocol on
the gfx blocklist, allowing us more control over feature deployment.
This will help with the slow rollout of WebRender to release channels.
Differential Revision: https://phabricator.services.mozilla.com/D56563
--HG--
extra : moz-landing-system : lando
This patch also exposes the desktop environment and window protocol on
the gfx blocklist, allowing us more control over feature deployment.
This will help with the slow rollout of WebRender to release channels.
Differential Revision: https://phabricator.services.mozilla.com/D56563
--HG--
extra : moz-landing-system : lando
Currently, when task system-symbols-mac doesn't produce artifacts because of no data, then the task system-symbols-mac-upload-symbols is failing too.
So this patch aims to not fail the task in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D59848
--HG--
extra : moz-landing-system : lando
The issue was caused by us making a copy of the platform writer thus
triggering the destructor twice.
Differential Revision: https://phabricator.services.mozilla.com/D61477
--HG--
extra : moz-landing-system : lando
This patch was generated with a script. It doesn't include all files:
- Files that use the preprocessor or fail to parse are skipped
- Files that are loaded as JSMs but don't use the .jsm extension are skipped (those will be renamed in Bug 1609269)
It was generated with the following command using d855222aa2/no-this-property-read.js:
```
hg revert --all &&
cp .gitignore .rgignore &&
rg --files-without-match -g '*.jsm' '^#endif|^#include|^#filter' | jscodeshift --stdin --transform ~/Code/jsm-rewrites/no-this-property-read.js --ignore-pattern ./mobile/android/modules/Sanitizer.jsm --ignore-pattern ./js/xpconnect/tests/unit/syntax_error.jsm &&
./mach eslint `hg st | rg '^M ' | sed 's/^M //'`
```
Differential Revision: https://phabricator.services.mozilla.com/D60187
--HG--
extra : moz-landing-system : lando
musl libc defines these to pread and pwrite respectively, since its
off_t is always 64-bit. This causes unintended macro replacement
when defining the pread64/pwrite64 wrappers.
To prevent this, save the macro definitions at the start of the
header and restore them at the end. This is what is already done
to work around the same issue on Android NDK.
This is a cherry-pick of the following upstream change:
https://chromium.googlesource.com/linux-syscall-support/+/f70e2f1641e280e777edfdad7f73a2cfa38139c7%5E%21/
This change was also applied to google-breakpad here:
647158232b%5E%21/
Differential Revision: https://phabricator.services.mozilla.com/D61205
--HG--
extra : moz-landing-system : lando
Implement Crash Report for Reporting API.
The browser test will force a crash of the renderer and check that a report is
sent to the server. Because of this (intentional) crash, the verification test
fail. So we disable verification test for that test.
Differential Revision: https://phabricator.services.mozilla.com/D58053
--HG--
extra : moz-landing-system : lando
This also adds an explicit warning when this happens so that the child processes don't crash without leaving a trace.
Differential Revision: https://phabricator.services.mozilla.com/D60650
--HG--
extra : moz-landing-system : lando
While this information is often included in crash stacks, there are a few
situations where this probe can give us better information:
* Sometimes we get absolute garbage for part of the stack, and having
information off to the side could help clarify things.
* Sometimes many different runnables get their Run() method merged through code
folding, and so the Run() you see in the stack is very much not what you would
expect to see. Having the runnable name be available could help clarify things.
* This data may be easier to work with in bulk as it is a separate,
well-defined, field.
Differential Revision: https://phabricator.services.mozilla.com/D59364
--HG--
extra : moz-landing-system : lando
While this information is often included in crash stacks, there are a few
situations where this probe can give us better information:
* Sometimes we get absolute garbage for part of the stack, and having
information off to the side could help clarify things.
* Sometimes many different runnables get their Run() method merged through code
folding, and so the Run() you see in the stack is very much not what you would
expect to see. Having the runnable name be available could help clarify things.
* This data may be easier to work with in bulk as it is a separate,
well-defined, field.
Differential Revision: https://phabricator.services.mozilla.com/D59364
--HG--
extra : moz-landing-system : lando
Currently, when task system-symbols-mac doesn't produce artifacts because of no data, then the task system-symbols-mac-upload-symbols is failing too.
So this patch aims to not fail the task in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D59848
--HG--
extra : moz-landing-system : lando
When a content or plug-in process crashes too early we haven't initialized the
CrashReporterHost for that process. This will cause the crash to be orphaned,
i.e. to miss most of its crash annotations. We added code to finalize those
crashes in bug 1282776 so that we wouldn't miss them entirely. This ensured
that crash reports would have both their .dmp and .extra files but the patch
failed to modify the code that notified various listeners about the crash
report's presence.
This changes always send the crash ID alongside the crash notifications, even
for orphaned crashes, so that listeners such as the content crash handler or
the test harnesses can always find the minidump and .extra file. Additionally
orphaned crashes are recorded in the CrashManager and in telemetry just like
normal crashes.
This also re-enables dom/ipc/tests/process_error.xul which failed frequently
because of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D57634
--HG--
extra : moz-landing-system : lando
Bug 151627 - Add "Submit All" button to about:crashes to submit all pending crashes with single click.
Differential Revision: https://phabricator.services.mozilla.com/D28275
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
We wait for the crash to be recorded in the crash manager only for the
submission that will also be recorded. This is required because those crashes
are either content or plug-in crashes and the crash manager is aware of them.
Crash reports submitted from about:crashes are not recorded because they are
not known to the crash manager and thus we shouldn't wait for them.
Differential Revision: https://phabricator.services.mozilla.com/D55971
--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 rolls up all the required changes for this purpose. Since the
whole crash reporting flow must understand the new format it's not possible
to land this as separate patches as individually they would be broken. This
patch includes the following changes:
* Changes to the crash reporting machinery to write out annotations as JSON,
these includes changes to the DLL blocklist code that must be run at crash
time.
* Modifications to the crash reporter client so that it can read and
submit the new format; this includes platform-specific changes to the
Breakpad libraries it uses for submitting crashes.
* Modifications to the minidump-analyzer to understand and process the new
format correctly.
* Modifications to the crash manager to understand and process the new format
correctly.
* Modifications to GeckoView's crash handler to understand and submit the
new format correctly.
* Added new tests to cover the new format and modified existing ones to
accomodate the new one.
Differential Revision: https://phabricator.services.mozilla.com/D46848
--HG--
extra : moz-landing-system : lando
On some linux machines, the cpu flags exceed the max buffer size of 512 characters. Doubling the buffer size makes room for these flags, so the minidump writer doesn't exit after reading the first `flags` entry, which falsely interprets the highest cpu id as 0.
Differential Revision: https://phabricator.services.mozilla.com/D54610
--HG--
extra : moz-landing-system : lando
This change surfaces errors faster, and ensures that we don't silently
end up with empty crashreporter symbols if `dump_syms` can't run for
some reason.
Differential Revision: https://phabricator.services.mozilla.com/D43520
--HG--
extra : moz-landing-system : lando
This patch rolls up all the required changes for this purpose. Since the
whole crash reporting flow must understand the new format it's not possible
to land this as separate patches as individually they would be broken. This
patch includes the following changes:
* Changes to the crash reporting machinery to write out annotations as JSON,
these includes changes to the DLL blocklist code that must be run at crash
time.
* Modifications to the crash reporter client so that it can read and
submit the new format; this includes platform-specific changes to the
Breakpad libraries it uses for submitting crashes.
* Modifications to the minidump-analyzer to understand and process the new
format correctly.
* Modifications to the crash manager to understand and process the new format
correctly.
* Modifications to GeckoView's crash handler to understand and submit the
new format correctly.
* Added new tests to cover the new format and modified existing ones to
accomodate the new one.
Differential Revision: https://phabricator.services.mozilla.com/D46848
--HG--
extra : moz-landing-system : lando
The minidump-analyzer tool was originally conceived to be used from the crash
report client and as such was installed in the crash reporter client
application bundle on macOS. It was later adapted to work from Firefox itself
but this caused linking problems when invoked from the Firefox app bundle.
This patch moves the minidump-analyzer into the Firefox app bundle and adapts
the relevant code to find it there.
The minidump-analyzer was also not signed like the rest of our executables and
this patch addresses that issue too.
Differential Revision: https://phabricator.services.mozilla.com/D52910
--HG--
extra : moz-landing-system : lando
Currently the PHC code uses char* and uintptr_t in various address
computations. This patch changes it to use uint8_t* instead, which is clearer
than char* and avoids the need for various casts.
Differential Revision: https://phabricator.services.mozilla.com/D43840
--HG--
extra : moz-landing-system : lando
This patch uses the low memory resource notification facility to detect
scenarios where physical memory is running low without polling. This is a
significant change compared to the previous behavior which measured both
available virtual memory (only on 32-bit builds) and available commit space.
Since we're not trying to avoid OOMs anymore we don't save memory reports
anymore when hitting a low-memory condition.
Differential Revision: https://phabricator.services.mozilla.com/D50471
--HG--
extra : moz-landing-system : lando
This patch uses the low memory resource notification facility to detect
scenarios where physical memory is running low without polling. This is a
significant change compared to the previous behavior which measured both
available virtual memory (only on 32-bit builds) and available commit space.
Since we're not trying to avoid OOMs anymore we don't save memory reports
anymore when hitting a low-memory condition.
Differential Revision: https://phabricator.services.mozilla.com/D50471
--HG--
extra : moz-landing-system : lando
Some paths contain symlinks and Python normpath doesn't resolve them.
So it results on having wrong paths in generated breakpad file.
Differential Revision: https://phabricator.services.mozilla.com/D48075
--HG--
extra : moz-landing-system : lando
* At this point our DLL blocking infra is complicated enough that I decided to
bite the bullet and move all of this code out of `mozglue/build` and into its
own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
receives a vector containing all saved records of loaded DLLs that happened
until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
any other non-`firefox` processes that do not have a launcher process
providing a loader API.
* We add some wide to UTF8 conversion functions.
Depends on D43157
Differential Revision: https://phabricator.services.mozilla.com/D43158
--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : browser/app/winlauncher/freestanding/LoaderAPIInterfaces.h => mozglue/dllservices/LoaderAPIInterfaces.h
rename : browser/app/winlauncher/freestanding/ModuleLoadInfo.h => mozglue/dllservices/ModuleLoadInfo.h
rename : browser/app/winlauncher/NtLoaderAPI.h => mozglue/dllservices/NtLoaderAPI.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
* At this point our DLL blocking infra is complicated enough that I decided to
bite the bullet and move all of this code out of `mozglue/build` and into its
own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
receives a vector containing all saved records of loaded DLLs that happened
until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
any other non-`firefox` processes that do not have a launcher process
providing a loader API.
* We add some wide to UTF8 conversion functions.
Differential Revision: https://phabricator.services.mozilla.com/D43158
--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
* At this point our DLL blocking infra is complicated enough that I decided to
bite the bullet and move all of this code out of `mozglue/build` and into its
own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
receives a vector containing all saved records of loaded DLLs that happened
until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
any other non-`firefox` processes that do not have a launcher process
providing a loader API.
* We add some wide to UTF8 conversion functions.
Differential Revision: https://phabricator.services.mozilla.com/D43158
--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
* At this point our DLL blocking infra is complicated enough that I decided to
bite the bullet and move all of this code out of `mozglue/build` and into its
own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
receives a vector containing all saved records of loaded DLLs that happened
until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
any other non-`firefox` processes that do not have a launcher process
providing a loader API.
* We add some wide to UTF8 conversion functions.
Differential Revision: https://phabricator.services.mozilla.com/D43158
--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
Bug 1558372 allows to build crash reporter for Android even if host isn't
Linux. But when using Windows host, it is still broken.
Host libraries and tools in `toolkit/crashreporter/google-breakpad/src/common`
is only for Linux host and macOS host. So if using Windows host, it isn't
buildable. So I would like to exclude this if host is windows.
Also, `toolkit/crashreporter/google-breakpad/src/tools/linux/dump_syms` is
only for Linux host.
Differential Revision: https://phabricator.services.mozilla.com/D43923
--HG--
extra : moz-landing-system : lando
Even if we don't see error messages from `llvm-dsymutil`, we can still
generate dSYM bundles that `dump_syms` completely falls over on. Let's
implement a super-careful check that actually examines the debug
information produced to ensure that `dump_syms` will accept our bundle.
Differential Revision: https://phabricator.services.mozilla.com/D44529
--HG--
extra : moz-landing-system : lando
Mike Hommey
Nathan Froyd
Andrew Halberstadt
Csoregi Natalia
David Teller
Cameron McCormack
Gabriele Svelto
Ricky Stewart
Nika Layzell
Simon Giesecke
Sylvestre Ledru
Jared Wein
Dorel Luca
Roger Yang
Nicklas Boman
Greg V
Ian Moody
Gijs Kruitbosch
Andreea Pavel
Stephen A Pohl
Daniel Varga
sumagnadas
Jan Beich
Chris Peterson
Barret Rennie
André Bargull
Nicholas Nethercote
Brindusan Cristian
Michael Forney
Ciure Andrei
Ed Lee
Jason Adler
Bogdan Tara
Andrew McCreight
Eric Rahm
Arnaud Renevier
Mike Shal
Cosmin Sabou
Kristen Wright
Andrew Osmond
Razvan Maries
Calixte Denizet
Brian Grinstead
Mihai Alexandru Michis
Marco Castelluccio
Brian Hackett
Arthur Iakab
Manish Giri
Aaron Klotz
inspiro
Kris Maglione
shindli
Noemi Erli
qiaopengcheng
Steven Michaud
Gurzau Raul
Jan Varga
Anny Gakhokidze
Christoph Kerschbaumer
monikamaheshwari
Makoto Kato
Itiel