We have prebuilt dump_syms binaries in toolkit/crashreporter/tools/win32 from
the days when we didn't build it as part of the build. There's one per MSVC
version, since the APIs it uses are version-specific, but we don't actually
support building with the MSVC versions corresponding to the binaries in that
directory anymore, so we should just remove them.
The only code change necessary here is changing the functional test to skip
running the test if a dump_syms binary isn't available.
MozReview-Commit-ID: IBuJZMVfv7C
Differential Revision: https://phabricator.services.mozilla.com/D15717
--HG--
extra : moz-landing-system : lando
This backs out the main patch landed earlier in bug 1194856 and the
patch from bug 1225004.
Differential Revision: https://phabricator.services.mozilla.com/D14050
--HG--
extra : moz-landing-system : lando
But keep the crashreporter disabled at runtime because it doesn't work
yet.
This has the side effect of creating the artifacts with the
crashreporter symbols and pdbs.
Differential Revision: https://phabricator.services.mozilla.com/D14550
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
This makes a few small but significant changes to the logic breakpad uses to
merge module memory mappings:
- First of all we merge areas of reserved space if their offset is either 0 or
the end of the previous non-reserved mapping.
- Whenever we encounter an executable mapping we flag all the merged modules
as executable. This shouldn't happen but apparently some older Android
linkers suffered from a bug that caused the first mapping not to be
executable.
- Last but not least we record the raw end address of a module on Android.
This shouldn't affect us but it's done in upstream breakpad so it probably
doesn't hurt.
Differential Revision: https://phabricator.services.mozilla.com/D12113
--HG--
extra : moz-landing-system : lando
Previously, our panic hook was only really useful when the crash
reporter is used, because all it did apart from calling rust's default
panic handler was to keep a pointer to the panic message for the crash
reporter.
Now that it just redirects to the Gecko crash code, it doesn't need to
be tied to the crash reporter. In fact, to ensure it's consistently used
in all cases, we ought to install it early on. Use a static initializer
for that.
Depends on D11720
Depends on D11720
Differential Revision: https://phabricator.services.mozilla.com/D11721
--HG--
extra : moz-landing-system : lando
The current rust panic hook keeps a string for the crash reporter, and
goes on calling the default rust panic hook, which prints out a crash
stack... when RUST_BOOTSTRAP is set *and* when that works. Notably, on
both mac and Windows, it only really works for local builds, but fails
for debug builds from automation, although on automation itself, we also
do stackwalk from crash minidumps, which alleviates the problem.
Artifact debug builds are affected, though.
More importantly, C++ calls to e.g. MOZ_CRASH have a similar but
different behavior, in that they dump a stack trace on debug builds, by
default (with exceptions, see below for one). The format of those stack
traces is understood by the various fix*stack*py scripts under
tools/rb/, that are used by the various test harnesses both on
automation and locally.
Additionally, the current rust panic hook, as it calls the default rust
panic hook, ends up calling abort() on non-Windows platforms, which ends
up being verbosely redirected to mozalloc_abort per
https://dxr.mozilla.org/mozilla-central/rev/237e4c0633fda8e227b2ab3ab57e417c980a2811/memory/mozalloc/mozalloc_abort.cpp#79
which then calls MOZ_CRASH. Theoretically, /that/ would also print a
stack trace, but doesn't because currently the stack trace printing code
lives in libxul, and MOZ_CRASH only calls it when compiled from
libxul-code, which mozalloc_abort is not part of.
With this change, we make the rust panic handler call back into
MOZ_CRASH directly. This has multiple advantages:
- This is more consistent cross-platforms (Windows is not special
anymore).
- This is more consistent between C++ and rust (stack traces all look
the same, and can all be post-processed by fix*stack*py if need be)
- This is more consistent in behavior, where debug builds will show
those stack traces without caring about environment variables.
- It demangles C++ symbols in rust-initiated stack traces (for some
reason that didn't happen with the rust panic handler)
A few downsides:
- the loss of demangling for some rust symbols.
- the loss of addresses in the stacks, although they're not entirely
useful
- extra empty lines.
The first should be fixable later one. The latter two are arguably
something that should be consistent across C++ and rust, and should be
changed if necessary, independently of this patch.
Depends on D11719
Depends on D11719
Differential Revision: https://phabricator.services.mozilla.com/D11720
--HG--
extra : moz-landing-system : lando
Previously, our panic hook was only really useful when the crash
reporter is used, because all it did apart from calling rust's default
panic handler was to keep a pointer to the panic message for the crash
reporter.
Now that it just redirects to the Gecko crash code, it doesn't need to
be tied to the crash reporter. In fact, to ensure it's consistently used
in all cases, we ought to install it early on. Use a static initializer
for that.
Depends on D11720
Differential Revision: https://phabricator.services.mozilla.com/D11721
--HG--
extra : moz-landing-system : lando
The current rust panic hook keeps a string for the crash reporter, and
goes on calling the default rust panic hook, which prints out a crash
stack... when RUST_BOOTSTRAP is set *and* when that works. Notably, on
both mac and Windows, it only really works for local builds, but fails
for debug builds from automation, although on automation itself, we also
do stackwalk from crash minidumps, which alleviates the problem.
Artifact debug builds are affected, though.
More importantly, C++ calls to e.g. MOZ_CRASH have a similar but
different behavior, in that they dump a stack trace on debug builds, by
default (with exceptions, see below for one). The format of those stack
traces is understood by the various fix*stack*py scripts under
tools/rb/, that are used by the various test harnesses both on
automation and locally.
Additionally, the current rust panic hook, as it calls the default rust
panic hook, ends up calling abort() on non-Windows platforms, which ends
up being verbosely redirected to mozalloc_abort per
https://dxr.mozilla.org/mozilla-central/rev/237e4c0633fda8e227b2ab3ab57e417c980a2811/memory/mozalloc/mozalloc_abort.cpp#79
which then calls MOZ_CRASH. Theoretically, /that/ would also print a
stack trace, but doesn't because currently the stack trace printing code
lives in libxul, and MOZ_CRASH only calls it when compiled from
libxul-code, which mozalloc_abort is not part of.
With this change, we make the rust panic handler call back into
MOZ_CRASH directly. This has multiple advantages:
- This is more consistent cross-platforms (Windows is not special
anymore).
- This is more consistent between C++ and rust (stack traces all look
the same, and can all be post-processed by fix*stack*py if need be)
- This is more consistent in behavior, where debug builds will show
those stack traces without caring about environment variables.
- It demangles C++ symbols in rust-initiated stack traces (for some
reason that didn't happen with the rust panic handler)
A few downsides:
- the loss of demangling for some rust symbols.
- the loss of addresses in the stacks, although they're not entirely
useful
- extra empty lines.
The first should be fixable later one. The latter two are arguably
something that should be consistent across C++ and rust, and should be
changed if necessary, independently of this patch.
Depends on D11719
Differential Revision: https://phabricator.services.mozilla.com/D11720
--HG--
extra : moz-landing-system : lando
Previously, our panic hook was only really useful when the crash
reporter is used, because all it did apart from calling rust's default
panic handler was to keep a pointer to the panic message for the crash
reporter.
Now that it just redirects to the Gecko crash code, it doesn't need to
be tied to the crash reporter. In fact, to ensure it's consistently used
in all cases, we ought to install it early on. Use a static initializer
for that.
Depends on D11720
Differential Revision: https://phabricator.services.mozilla.com/D11721
--HG--
extra : moz-landing-system : lando
The current rust panic hook keeps a string for the crash reporter, and
goes on calling the default rust panic hook, which prints out a crash
stack... when RUST_BOOTSTRAP is set *and* when that works. Notably, on
both mac and Windows, it only really works for local builds, but fails
for debug builds from automation, although on automation itself, we also
do stackwalk from crash minidumps, which alleviates the problem.
Artifact debug builds are affected, though.
More importantly, C++ calls to e.g. MOZ_CRASH have a similar but
different behavior, in that they dump a stack trace on debug builds, by
default (with exceptions, see below for one). The format of those stack
traces is understood by the various fix*stack*py scripts under
tools/rb/, that are used by the various test harnesses both on
automation and locally.
Additionally, the current rust panic hook, as it calls the default rust
panic hook, ends up calling abort() on non-Windows platforms, which ends
up being verbosely redirected to mozalloc_abort per
https://dxr.mozilla.org/mozilla-central/rev/237e4c0633fda8e227b2ab3ab57e417c980a2811/memory/mozalloc/mozalloc_abort.cpp#79
which then calls MOZ_CRASH. Theoretically, /that/ would also print a
stack trace, but doesn't because currently the stack trace printing code
lives in libxul, and MOZ_CRASH only calls it when compiled from
libxul-code, which mozalloc_abort is not part of.
With this change, we make the rust panic handler call back into
MOZ_CRASH directly. This has multiple advantages:
- This is more consistent cross-platforms (Windows is not special
anymore).
- This is more consistent between C++ and rust (stack traces all look
the same, and can all be post-processed by fix*stack*py if need be)
- This is more consistent in behavior, where debug builds will show
those stack traces without caring about environment variables.
- It demangles C++ symbols in rust-initiated stack traces (for some
reason that didn't happen with the rust panic handler)
A few downsides:
- the loss of demangling for some rust symbols.
- the loss of addresses in the stacks, although they're not entirely
useful
- extra empty lines.
The first should be fixable later one. The latter two are arguably
something that should be consistent across C++ and rust, and should be
changed if necessary, independently of this patch.
Depends on D11719
Differential Revision: https://phabricator.services.mozilla.com/D11720
--HG--
extra : moz-landing-system : lando
This also refactors the surrounding code for better readability and removes
some duplicate code.
Differential Revision: https://phabricator.services.mozilla.com/D11030
--HG--
extra : moz-landing-system : lando
SxS assemblies do not obey the usual DLL search order. It will make it possible
to load mozglue.dll from appdir even if the PreferSystem32Images mitigation is
enabled and System32 has a random mozglue.dll.
In bug 1388134 we're lazifying some members of OS.Constants.Path
to avoid the extra startup IO. userApplicationDataDir is ripe for
being made lazy, except it's read early in CrashManager.jsm. This
defers that until it's used, and adjusts the affected tests.
Depends on D6079
Differential Revision: https://phabricator.services.mozilla.com/D6080
--HG--
extra : moz-landing-system : lando
In bug 1388134 we're lazifying some members of OS.Constants.Path
to avoid the extra startup IO. userApplicationDataDir is ripe for
being made lazy, except it's read early in CrashManager.jsm. This
defers that until it's used, and adjusts the affected tests.
Depends on D6079
Differential Revision: https://phabricator.services.mozilla.com/D6080
--HG--
extra : moz-landing-system : lando
Add env var MOZ_DISABLE_EXCEPTION_HANDLER_SIGILL so that the crash
reporter will not register a handler for SIGILL when the env var is set.
This is needed to work around a conflict with the Oculus Mobile runtime
that uses the SIGILL signal to trap the back button on the controller.
Differential Revision: https://phabricator.services.mozilla.com/D6696
--HG--
extra : moz-landing-system : lando
Jed Davis
Gabriele Svelto
Ted Mielczarek
Mike Hommey
Cameron McCormack
Sylvestre Ledru
Ehsan Akhgari
Nathan Froyd
Michael Froman
Dorel Luca
Coroiu Cristina
Bogdan Tara
Errolyn
Masatoshi Kimura
Doug Thayer
Stephen A Pohl
Narcis Beleuzu
Randall Barker
Brindusan Cristian
arthur.iakab
Carl Corcoran