We see a number of crashes in Sentry that appear to be crashes in wasmtime. This shouldn't happen, as wasmtime is designed to run untrusted code "safely". Looking into this, it seems likely that the problem is that we race with wasmtime when installing signal handlers. If wasmtime's handlers are installed before ours, then any signals that it intends to handle (like out of bounds memory access) will reach our handlers before its; which causes us to assume the app has crashed. This changes fixes our crash handler initialization to ensure we always create our signal handler first, and reverts a previous attempt to fix this from #40883 Closes #ISSUE Before you mark this PR as ready for review, make sure that you have: - [ ] Added a solid test coverage and/or screenshots from doing manual testing - [ ] Done a self-review taking into account security and performance aspects - [ ] Aligned any UI changes with the [UI checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) Release Notes: - Linux: Fixed crashes that could happen due to our crash handler erroneously catching signals intended for wasmtime.
35 lines
683 B
TOML
35 lines
683 B
TOML
[package]
|
|
name = "crashes"
|
|
version = "0.1.0"
|
|
publish.workspace = true
|
|
edition.workspace = true
|
|
license = "GPL-3.0-or-later"
|
|
|
|
[dependencies]
|
|
bincode.workspace = true
|
|
cfg-if.workspace = true
|
|
crash-handler.workspace = true
|
|
futures.workspace = true
|
|
log.workspace = true
|
|
minidumper.workspace = true
|
|
|
|
paths.workspace = true
|
|
release_channel.workspace = true
|
|
smol.workspace = true
|
|
serde.workspace = true
|
|
serde_json.workspace = true
|
|
system_specs.workspace = true
|
|
zstd.workspace = true
|
|
|
|
[target.'cfg(target_os = "macos")'.dependencies]
|
|
mach2.workspace = true
|
|
|
|
[target.'cfg(target_os = "windows")'.dependencies]
|
|
windows.workspace = true
|
|
|
|
[lints]
|
|
workspace = true
|
|
|
|
[lib]
|
|
path = "src/crashes.rs"
|