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

[Ms2ger]

Haven't investigated further.

CC @michaelwu @jdm @Manishearth

[michaelwu]

Generally this assertion gets hit when servo panics with a RootedObject/RootedValue on stack. The panic prevents the destructor for the root from running, which then breaks this particular assertion. Destructors for GC thing roots have to be run in the correct order or all hell breaks loose.

This can also happen if someone tries to return or move a RootedObject/Value without appropriate use of the new_with_addr function.

[Ms2ger]

Destructors should still run after a panic, though

[jdm]

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

[Ms2ger]

If that's the case, the stack looks like [dead C++ object]+ [our Rust object], right? Then how about we just remove all the dead C++ objects as well?

[jdm]

Just keep popping until we get to the expected address, you mean? That would help with this assertion, but anything like JSAutoRequest would leave unfinished requests, etc. which will likely trigger more assertions.

[jdm]

rust-lang/rfcs#1413 looks like it could be useful.

[DemiMarie]

I suspect that the best approach is to catch all panics at every in-call to Rust and kill either the thread or process immediately, or kill JavaScript execution (by returning false without raising a JS exception) and then store the panic value in TLS. This is then checked on return to Rust and propogated.