-
Notifications
You must be signed in to change notification settings - Fork 13.4k
SIGILLs when panicking #48088
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
If you're getting a SIGILL because it executed a |
Yes, I know that. Moreover, it's not a user-code but exception frame clean-ups ("landing pads" or whatever it's called), so I have a strong suspicion that something changed/regressed in compiler. |
@alexcrichton |
Sounds a lot like #46833. |
@nagisa @diwic @arielb1
EDIT: |
Those should work just fine, as
Such lint would definitely be very false-positive happy, so it has no place in the compiler. |
Ok, I got it. Still #[unwind] does not work. What I did is:
and actual function definition
... for each function marked as "extern" and it still triggers UB on latest nightly. |
Looking at MSDN's docs for vectorcall - which I assume is what "vectorcall" refers to - it does not mention how to handle exceptions, stack unwinding, etc. So I guess it's fair to say that exceptions/panics are not supported in this calling convention. But if vectorcall is actually faster than rust-call, then we should create a new rust-vectorcall convention, which does support panics and uses registers/stack just as MS vectorcall does. (And then we could try switching to it by default, if the majority of calls are quicker with that.) |
At least for Windows, exceptions and stack unwinding are handled in a standardized way using SEH, and independent of the calling convention used. The only thing that gets in the way of unwinding across those function boundaries is the fact that that Rust emits the Because the |
Thanks for reporting this! We already knew about this problem, but it was decided to keep sending SIGILLs when a panic occurs across Please open another issue about |
Uh oh!
There was an error while loading. Please reload this page.
Hi
I am trying to debug some regression in compiler leading to triggering SIGILLs when raising exceptions/panicking. More precisely, SIGILLs happen at unwinding stage after drop_in_place calls in frame cleaning. Technically it's seen as a jump to ud2 instruction.
Quick bisecting using precompiled binaries resulted in finding nightly-2017-12-25-x86_64-unknown-linux-gnu as the first culprit. nightly-2017-12-24-x86_64-unknown-linux-gnu still works fine.
Unfortunately, I cannot reproduce it in easy test-case.
I am under Linux x64, no optimization/debug build.
I'll try to bisect using git, but recompiling compiler is really slow, so results are not coming quickly.
The text was updated successfully, but these errors were encountered: