Drop::drop() not called on a panic! when compiling to WASM

[coolreader18]

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".

[ids1024]

When you say wasm, I presume you mean the wasm32-unknown-emscripten target?

Panic isn't guaranteed to result in destructors being called; this depends on whether panic=unwind or panic=abort is used. Normally this is configured in Cargo.toml, but some targets may support only abort, which wouldn't result in destructors being run.

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.

[coolreader18]

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 std works with WASM.

[ids1024]

Ah yeah, with wasm32-unknown-unknown I'm not surprised it doesn't work.

Maybe there could be documentation for this, because this seems like fairly unexpected behavior, especially when most of std works with WASM.

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 panic=abort).

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 Drop, or even the documentation for panic!.

[alexcrichton]

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.

[coolreader18]

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?

[alexcrichton]

I'd recommend following https://github.com/WebAssembly/exception-handling which is the standard we'll use once implemented in browsers.

[gmorenz]

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?

[lukechu10]

Sorry for the ping but with exception handling implemented in both Chrome and Safari, any chance for progress on this issue?