This includes some assorted fixes from upstream plus an adaptation of the
patch in b988fa74ec18de6214b18f723e48331d9a7802ae which includes heap memory
regions in the minidump. Since our support for that is more extensive than
upstream breakpad the resulting change reflects this. Last but not least the
fixes for bug 1489094 and bug 1511140 were split out as patches to be applied
to the unmodified breakpad sources. They will be reintegrated as soon as we
fork breakpad for good.
Differential Revision: https://phabricator.services.mozilla.com/D16326
--HG--
extra : moz-landing-system : lando
We currently rely on WIN_DIA_SDK_BIN_DIR being passed, but we can
actually derive it from the DIA SDK directory. So we now do that, except
when it's given explicitly.
While in the vicinity, move the dia2.h check to python configure.
With WIN_DIA_SDK_BIN_DIR being derived and not set when dia2.h is not
found, we don't really need MSVC_HAS_DIA_SDK anymore, so we just check
for WIN_DIA_SDK_BIN_DIR to determine whether to build dump_syms or not.
One exception to the above is when WIN_DIA_SDK_BIN_DIR is passed in,
which we only keep for the in-tree mozconfigs for now. We'll remove that
possibility after bug 1523201.
Depends on D17892
Differential Revision: https://phabricator.services.mozilla.com/D17893
--HG--
extra : moz-landing-system : lando
We can't run dump_syms without the DIA SDK binary directory in $PATH
because dump_syms requires the DIA dll from there.
Obviously, the corresponding test can't run if the DIA SDK binary
directory is not known (rather than when the dia2.h header is not found,
since the build system currently relies on WIN_DIA_SDK_BIN_DIR being
given manually).
Differential Revision: https://phabricator.services.mozilla.com/D17892
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
Because the .xdata format on ARM64 can only encode sizes up to 1M (much too small for our JIT code regions), we register a function table callback to provide RUNTIME_FUNCTIONs at runtime. Windows doesn't seem to care about the size fields on RUNTIME_FUNCTIONs that are created in this way, so the same RUNTIME_FUNCTION can work for any address in the region. We'll set up a generic one in RegisterExecutableMemory and the callback can just return a pointer to it.
Differential Revision: https://phabricator.services.mozilla.com/D16261
--HG--
extra : moz-landing-system : lando
With `ac_add_options --enable-project=tools/crashreporter` in a
mozconfig, `./mach build` builds minidump_stackwalk, dump_syms
and fileid.
One caveat is that due to limitation in how the build system works
currently, it's cumbersome to keep dump_syms as a host program for
Gecko, and to make it a target program for this project. For now,
keep it as a host program. We're not going to use it on automation,
but it's still convenient to have for quick local builds (I've had
to resort to awful hacks downstream).
Differential Revision: https://phabricator.services.mozilla.com/D16299
--HG--
extra : moz-landing-system : lando
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
