I'm convinced that this is due to SpiderMonkey being compiled with -fno-exceptions (so destructors won't get run when we try to unwind through C++), as well as unwinding from Rust across FFI being undefined behaviour. The assertion appears to trigger because a C++ RootedValue is on the stack when the panic occurs, and its destructor doesn't end up getting run so our Rust destructor gets hopelessly confused. Potential ways forward include:

19:34 <jdm> consider a Window::Crash method that panics
19:34 <jdm> we're supposed to catch the panic before returning to the C++ caller of the binding method
19:34 <jdm> and then.... what?
19:34 <jdm> SM will think everything is fine
19:35 <jdm> and then we need to store the fact that we caught a panic somewhere (TLS?) and check that every time we return from any code that could end up returning to Rust code
19:35 <jdm> and re-panic

19:52 <pcwalton> this is a totally wacky idea, but could we throw a JavaScript exception to propagate the panic out?
19:52 <pcwalton> (assume we have magic JS exceptions that content can't catch)

19:54 <pcwalton> here's another weird idea: use catch_panic! and continue, but put an event in the event queue that will kill the script task
19:54 <pcwalton> that way script ends up dying once it reaches the outermost event boundary

Uh oh!

assertion failed: *self.stack == mem::transmute(&*self) in wpt #6462

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

assertion failed: `self.stack == mem::transmute(&self)` in wpt #6462