Drop::drop() not called on a panic! when compiling to WASM #58874
Comments
|
When you say wasm, I presume you mean the Panic isn't guaranteed to result in destructors being called; this depends on whether That said, there does seem to be an unwinding implementation for emscripten: https://github.com/rust-lang/rust/blob/master/src/libpanic_unwind/emcc.rs So I think this should work, but I don't have much experience with wasm. |
jonas-schievink
added
A-destructors
|
No, wasm32-unknown-unknown, compiled using wasm-pack/wasm-bindgen. Looking through the source code, it seems like the comment here explains what's going on pretty well. Maybe there could be documentation for this, because this seems like fairly unexpected behavior, especially when most of |
|
Ah yeah, with
In theory I think it's expected behavior for unwinding panics to not necessarily be available on all targets (and a library can't rely on it since an application could use But yeah, it doesn't seem to be documented too well. I don't see any mention of unwind vs abort in the documentation for |
|
The wasm32-unknown-unknown target is panic=abort by default which means that panics "abort" the process, which in this case is a native wasm trap. When the exception handling proposal is implemented we'll integrate with that and provide the ability to run destructors on panics, but at this time the wasm target doesn't support any form of destructors on unwinding. |
|
Ah yeah, thanks, luckily I was able to work around an issue where panics would break the entire application. Do you know of an ETA for when exception handling will be standardized/supported in wasm runtimes? |
|
I'd recommend following https://github.com/WebAssembly/exception-handling which is the standard we'll use once implemented in browsers. |
|
With that proposal now being implemented in v8, are we likely to see progress on this? Is there a rust issue to watch for this? |
Per rust-lang/rust#58874 re-entering a webasm instance that paniced is undefined behavior. The #[event(fetch)] macro currently inserts a panic in the case that the fetch handler returns an `Err`, this removes that panic.
|
Sorry for the ping but with exception handling implemented in both Chrome and Safari, any chance for progress on this issue? |
Running 1.34.0-nightly 2019-02-22, but it also happens on stable. Repr here: https://github.com/coolreader18/wasm-no-drop/.
I noticed this with an
Rc<RefCell<_>>, when I borrowed it mutably and something panicked while the borrow was held, trying to borrow that same RefCell again panicked with "already borrowed: BorrowMutError". This might be a wasm-bindgen error, cause it seems weird that this bug would go unnoticed for the whole time that wasm32-unknown-unknown has been stable (unless I missed the issue).Demo currently in production: https://rustpython.github.io/demo, add a line that contains
global x, click Run, remove that line, and try to run it again. There's a version of that that shows the panic error message, and the first time it's "not implemented: global` and the second time it's "borrow error".The text was updated successfully, but these errors were encountered: