This is a minimal implementation of a WER exception module that can intercept
crashes of Firefox processes and write out a fully formed crash report, that is
a minidump, an .extra file containing the minimum annotations required by
Socorro and an event file.
The module in and by itself is not functional: an entry needs to be added to
the registry and the processes which want to be monitored need to register it
at runtime. With this patch applied it will only be built but it won't be
packaged with Firefox nor it will be used when doing local development.
The module implementation has a few notable properties:
* We use an empty C++ shim (mozwer) to build the module DLL. This is
because the build system doesn't support building DLLs directly from Rust.
* The actual implementation is written in Rust (mozwer-rust) and exposes the
callbacks that will be invoked by the WER service.
* We use the winapi crate to access Windows native functionality but given it
is missing some bits (including upstream!) we declare them in our crate for
the time being.
* The minidump uses the same options we use in Firefox and should be of
similar size. I manually tested different type of crashes including
__fastail() ones and they're all reliably captured.
* The .extra file contains only the annotations that are strictly required for
submitting the crash to crash-stats.mozilla.org. More should be added in the
future. The existing annotations are all extracted from within the module
code because we have no way to access the ones that were stored in Firefox'
crashed processes (nor should we, since we hope to catch crashes that happen
even before Firefox sets up crash reporting internally).
* The module does not distinguish between main process and content process
crashes at the moment. This will need to be implemented when we hook it up
with the crash reporting code within Firefox.
* We use libc's time() function to get the crash time in order to be consistent
with what the regular exception handler does.
Differential Revision: https://phabricator.services.mozilla.com/D101708
The logic missed a pair of brackets, leading to memory regions
being merged that shouldn't have been merged (anonymous regions
with access flags set getting merged into the previous mapping)
Differential Revision: https://phabricator.services.mozilla.com/D106772
This is another WebGPU API update, it picks up a lot of changes that were made recently:
- new bind group layout
- new render pipeline descriptor
- new vertex formats
- limits
- compressed texture formats
- index format
- query sets
- and more small ones!
It also brings in the updated `gfx/wgpu` to support these API changes.
Differential Revision: https://phabricator.services.mozilla.com/D107013
This is another WebGPU API update, it picks up a lot of changes that were made recently:
- new bind group layout
- new render pipeline descriptor
- new vertex formats
- limits
- compressed texture formats
- index format
- query sets
- and more small ones!
It also brings in the updated `gfx/wgpu` to support these API changes.
Differential Revision: https://phabricator.services.mozilla.com/D107013
The mozjs_sys crate is actually responsible for all the problems
encountered with the js crate we just removed, but the sm-mozjs-crate
task that builds and runs tests for it doesn't fail because... there is
actually no test to build and run, so all it builds is a static library,
which doesn't expose all the problems that exist.
The content of this crate in mozilla-central is also outdated compared
to servo upstream.
Differential Revision: https://phabricator.services.mozilla.com/D106390
The sm-rust-bindings task that builds and runs tests for it actually only
doesn't fail by three(!) distinct happenstances of chance:
- It somehow doesn't hit a race condition that can happen, but that
attempting to change the build process for jsglue.cpp did,
- The second call to `cargo test` without `--feature debugmozjs` only
works because nothing was cleaned up from the first and the second
build uses artifacts from the first that are otherwise not there if
only running the second.
- The addition of rust code to spidermonkey (the jsrust crate in
js/src/rust) somehow didsn't cause problems in the current
configuration, but in other configurations (which fixing the second
thing above unveils) the build fails because of the multiple
definition of rust_eh_personality between the jsrust staticlib and the
rust stdlib that rustc links to test programs.
On top of all the above, the content of the crate in mozilla-central
has not received updates from upstream servo in years, and doesn't
reflect what servo actually uses.
Differential Revision: https://phabricator.services.mozilla.com/D106389
Now that we use an external dump_syms, we don't need to build
breakpad's.
This means we also don't need the dump_syms_rust_demangle crate anymore.
Differential Revision: https://phabricator.services.mozilla.com/D101865
Fixes errors like:
dependency (nix) specification is ambiguous. Only one of `branch`, `tag` or `rev` is allowed.
I've left the most specific dependency, but for wgpu the rev is not
right, so I've kept the branch which effectively preserves behavior.
Differential Revision: https://phabricator.services.mozilla.com/D100485
I'm keeping the --enable-update-agent config option and the corresponding
MOZ_UPDATE_AGENT config flag and define, as these should still be useful.
As we never shipped this there is no need to keep anything around to
clean up the scheduled tasks.
Differential Revision: https://phabricator.services.mozilla.com/D99574
Instantiating a wasm library duplicates a file descriptor for /dev/null 3 times to be used as input, output and error streams for the wasm sandboxed code. When a lot of sandboxes are created and destroyed, a lot of descriptors are duplicated and closed. While this should be fine, POSIX does not seem to happy with the opening and closing of many file descriptors --- this could perhaps be some strange interaction with Firefox's seccomp filters and cross-process file descriptor handling as it is difficult to repro this outside of firefox.
However, the simpler fix here was to just eliminate the duplication of /dev/null and return an error when input, output or error streams are accessed by wasm sandboxed code. This means calls to printf will fail, but no code I know off actually checks the int error code returned by printf and this change is certainly compatible with existing sandboxed components.
Differential Revision: https://phabricator.services.mozilla.com/D99160
Revendor Cranelift to 3b01b4b850bafb981a04383198c0b50d041dc5ef
from https://github.com/mozilla-spidermonkey/wasmtime branch firefox85.
The (only) purpose is to pull in this:
commit 31bac3eafbfda8f1ffb504cdeb75505d48537336
Merge: 93c199363 34d9931ed
Author: Nick Fitzgerald <fitzgen@gmail.com>
Date: Wed Nov 25 13:09:05 2020 -0800
Merge pull request #2450 from bytecodealliance/cfallin/fix-wasm-reachable
Fix Wasm translator bug: end of toplevel frame is branched-to only for fallthrough returns.
Differential Revision: https://phabricator.services.mozilla.com/D99204
On a very parallel debug build, I see a long time just waiting for
bindgen / style compilation / geckoservo.
Turns out that a bunch of this is just proc macros / build scripts.
Optimizing it saves between 10 and 17 seconds of my debug build. We
might want to consider running bindgen much like cbindgen rather than
rebuilding it all the time, which should help a lot more, but my guess
is that this should still help with the pretty hot custom derives that
the style crate runs.
This needs rust 1.41, so the requirement for tools/crashreporter needs
to be bumped as a consequence. To make things simpler, it was bumped
to 1.47 while we're at it.
Differential Revision: https://phabricator.services.mozilla.com/D98366
This updates the relevant CL and wasmparser versions:
* wasmparser 0.67
* Cranelift/wasmtime to dcc52ba3f69d3de7cdbd787b936825d9c61e3c27
on branch firefox85 at https://github.com/mozilla-spidermonkey/wasmtime
It also includes the following changes needed to track CL/wasmparser ABI changes:
* test suite: track improvements to validation-failure expected outputs.
* wasm/cranelift/src/bindings/mod.rs, ModuleEnvironment::signature: track
CL-side changes towards module-linking support.
* wasm/cranelift/src/wasm2clif.rs: FuncEnvironment::translate_memory_copy:
track CL-side changes for supporting multiple memories.
Differential Revision: https://phabricator.services.mozilla.com/D97587
This PR updates wgpu to the latest and changes the way we pass object descriptors to the GPU process.
Instead of trying to convert them between DOM-CPP-IPDL-FFI-Rust, we now do DOM-FFI-Rust
and serialize them by serde into ipc::ByteBuf objects.
Differential Revision: https://phabricator.services.mozilla.com/D94908
This PR updates wgpu to the latest and changes the way we pass object descriptors to the GPU process.
Instead of trying to convert them between DOM-CPP-IPDL-FFI-Rust, we now do DOM-FFI-Rust
and serialize them by serde into ipc::ByteBuf objects.
Differential Revision: https://phabricator.services.mozilla.com/D94908
This patch pulls in an updated Cranelift with a new validation strategy,
introduced by bytecodealliance/wasmtime#2059. This new design validates
the Wasm module as it parses the function bodies. A subsequent patch
will adapt Baldrdash to work with this.
Differential Revision: https://phabricator.services.mozilla.com/D92503
This patch pulls in an updated Cranelift with a new validation strategy,
introduced by bytecodealliance/wasmtime#2059. This new design validates
the Wasm module as it parses the function bodies. A subsequent patch
will adapt Baldrdash to work with this.
Differential Revision: https://phabricator.services.mozilla.com/D92503
This patch pulls in an updated Cranelift with a new validation strategy,
introduced by bytecodealliance/wasmtime#2059. This new design validates
the Wasm module as it parses the function bodies. A subsequent patch
will adapt Baldrdash to work with this.
Differential Revision: https://phabricator.services.mozilla.com/D92503
This patch pulls in the latest version of Cranelift, which includes
necessary updates to support some recent work on the Wasm backend (e.g.,
support for the new ABI in PR #2223).
Differential Revision: https://phabricator.services.mozilla.com/D92000
This patch pulls in the latest version of Cranelift, which includes
necessary updates to support some recent work on the Wasm backend (e.g.,
support for the new ABI in PR #2223).
Differential Revision: https://phabricator.services.mozilla.com/D92000
This Cranelift update to revision 379aed8092cd1241ec7839e77d05557b1dceb234
includes its PRs #2197 and #2194, which fix two Wasm translation bugs, as well a
other miscellaneous updates and fixes.
Fixes both Bug 1664453 and Bug 1663861.
Differential Revision: https://phabricator.services.mozilla.com/D90306
This PR pulls in the latest version of Cranelift, which pulls in
regalloc.rs v0.0.30 and consequently includes some improvements in
memory allocation rate during compilation. No behavior changes expected.
Differential Revision: https://phabricator.services.mozilla.com/D87479