search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
96.97k stars 12.53k forks source link

In debug mode, print a message for attempted unwind past FFI call #47932

Open joshtriplett opened 6 years ago

joshtriplett commented 6 years ago

See https://github.com/rust-lang/rust/issues/47616 and https://github.com/rust-lang/rust/pull/46833 . Rust now generates an abort rather than attempting to unwind through an FFI call. In debug mode, could we generate a friendly error message explaining that, rather than just aborting? (In release mode we should continue to just abort.)

diwic commented 6 years ago

Hmm, but this raises questions w r t "where should it be printed?" "In no_std, can we even print things?"

joshtriplett commented 6 years ago

no_std still has panic_fmt and similar. (If a particular implementation of that throws away the message, that's fine.)

diwic commented 6 years ago

Hmm, but calling panic_fmt in that context will likely cause another panic (because panic_fmt is supposed to start a panic), which we will then catch in the same context, and then call panic_fmt on, which will cause an infinite loop?

There might be a safe somewhere that causes such a double panic to abort the process, but I'm not sure we're then better off than we are today.

joshtriplett commented 6 years ago

@diwic Hmmm, fair point. We need the "fmt" part of panic_fmt, not the "panic" part. :)

nagisa commented 6 years ago

That would require adding a new lang item that would end up being required for essentially every binary. We already have quite a few cases where invoking UB will "just" crash with a SIGILL. I think it is better to just document common UBs that result in SIGILLs in a discoverable location and not sacrifice codegen quality or #[no_std] usability.

steveklabnik commented 4 years ago

Triage: since this ticket has been filed, the abort behavior has been rolled back, and there have been attempts to make this defined behavior in some cases. There's no movement I'm aware of on this specific issue, though.

BatmanAoD commented 3 years ago

This may be something @rust-lang/wg-ffi-unwind should look into, now that the behavior for "C" is once again guaranteed to abort (in nightly).