Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-23 Thread acrichton
> I think for release builds, we should have the following: Thanks for this information! For reference, I've responded on the RFC to the technical bits here. https://github.com/rust-lang/rfcs/pull/1513#issuecomment-200626686 > On Wed, Mar 23, 2016 at 7:38 PM, Ralph Giles wrote: > > so

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-23 Thread Brian Smith
Henri Sivonen wrote: > I think for release builds, we should have the following: > 1) Rust panic!() causes a crash that's MOZ_CRASH()-compatible for > crash-reporting purposes. (See > https://mxr.mozilla.org/mozilla-central/source/mfbt/Assertions.h#269 > and particularly >

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-23 Thread Henri Sivonen
On Wed, Mar 23, 2016 at 1:17 AM, Ted Mielczarek wrote: > On Tue, Mar 22, 2016, at 06:51 PM, Brian Smith wrote: >> On Tue, Mar 22, 2016 at 3:03 AM, Henri Sivonen >> wrote: >> >> > It seems that the Rust MP4 parser is run a new Rust-created thread in >> >

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-23 Thread Ralph Giles
On Tue, Mar 22, 2016 at 3:51 PM, Brian Smith wrote: > Is the Rust MP4 parser using panics for flow control (like is common in JS > and Java with exceptions), or only for "should be impossible" situations > (like MOZ_CRASH in Gecko)? We're not using panics for flow control.

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-23 Thread Alex Crichton
Ah, no, if using `panic::recover` then it wouldn't translate to a crash (I believe) as it's just normal execution. If you want a panic in Rust to translate to an abort of the entire process, however, then you've got two options. On one hand you could use the custom panic hook support I mentioned

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-22 Thread Ted Mielczarek
On Tue, Mar 22, 2016, at 06:51 PM, Brian Smith wrote: > On Tue, Mar 22, 2016 at 3:03 AM, Henri Sivonen > wrote: > > > It seems that the Rust MP4 parser is run a new Rust-created thread in > > order to catch panics. > > > > Is the Rust MP4 parser using panics for flow

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-22 Thread Brian Smith
On Tue, Mar 22, 2016 at 3:03 AM, Henri Sivonen wrote: > It seems that the Rust MP4 parser is run a new Rust-created thread in > order to catch panics. > Is the Rust MP4 parser using panics for flow control (like is common in JS and Java with exceptions), or only for

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-22 Thread acrichton
> Ok, so that should be released in about 2 months, right? I believe so, yes! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-22 Thread Bobby Holley
On Tue, Mar 22, 2016 at 11:02 AM, wrote: > > My code doesn't currently use panic::recover. What > > happens when somebody doesn't use it and an exception hits the FFI > > boundary? Undefined behavior? > > Technically, yes, undefined behavior. It's specifically undefined to

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-22 Thread acrichton
> My code doesn't currently use panic::recover. What > happens when somebody doesn't use it and an exception hits the FFI > boundary? Undefined behavior? Technically, yes, undefined behavior. It's specifically undefined to unwind past an FFI boundary. Practically on Linux this will abort the

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-22 Thread Bobby Holley
On Tue, Mar 22, 2016 at 10:13 AM, wrote: > Ah, no, if using `panic::recover` then it wouldn't translate to a crash (I > believe) as it's just normal execution. I'm confused by this. My code doesn't currently use panic::recover. What happens when somebody doesn't use it

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-22 Thread acrichton
Ah, no, if using `panic::recover` then it wouldn't translate to a crash (I believe) as it's just normal execution. If you want a panic in Rust to translate to an abort of the entire process, however, then you've got two options. On one hand you could use the custom panic hook support I mentioned

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-22 Thread Bobby Holley
Does this mean that the default behavior in the main-thread FFI case is to abort the process in a way that invokes the crash reporter? Because I think that (along with zero-overhead) what Henri (and I) want. On Tue, Mar 22, 2016 at 9:45 AM, wrote: > Hello! I do agree it

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-22 Thread acrichton
Hello! I do agree it is indeed bad to spawn a new thread for all calls into Rust :). You likely don't want a custom panic handler [1], however, as those are actually more appropriately called "hooks" (just renamed [2]). Instead, the `std::panic::recover` function [3] is what you'll want for

Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-22 Thread Josh Matthews
On 2016-03-22 9:03 AM, Henri Sivonen wrote: It seems that the Rust MP4 parser is run a new Rust-created thread in order to catch panics. Once we introduce Rust code that intermingles with C++ more, it won't be practical to put all potentially panicing Rust code into dedicated threads. Can we

Mapping Rust panics to MOZ_CRASH on non-Rust-created threads

2016-03-22 Thread Henri Sivonen
It seems that the Rust MP4 parser is run a new Rust-created thread in order to catch panics. Once we introduce Rust code that intermingles with C++ more, it won't be practical to put all potentially panicing Rust code into dedicated threads. Can we install a custom panic function that detects