-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Consider producing more friendly output with runtime drop flag checking #35101
Comments
This is mostly solved by not having filling drop (cough… MIR… cough). In case anybody still wants to fix this issue, the relevant TRAP likely comes from code generated by rust/src/librustc_trans/glue.rs Line 314 in d1df3fe
|
Printing a message, though, would essentially mean extra code in every single drop glue. I wonder if that’s really the tradeoff anybody would be interested in making. |
@nagisa could this be debug-build-only? I would imagine having the function that emits the message just write a string to stderr before raising the signal itself. On the other hand the current implementation helps debugging because it traps into the debugger. |
This is not a purely zeroing drop issue: if you are using an enum instead of a struct, mangling the discriminant will cause an out-of-range switch and random UB (often a |
Indeed, I'm getting a |
Would Valgrind detect this? If not, I suspect that Rust needs ASan and UBSan support. |
filling drop is now a thing of the past. You can't corrupt drop flags without hardcore stack corruption now. |
This produces absolutely zero output in the playground because it generates a SIGTRAP and kills the program. Of course, it's hard to do much at this point because the program is in an unknown, probably-corrupt state, but we could at least print a message to stderr noting what happened.
Originally reported at https://internals.rust-lang.org/t/im-moving-away-heres-my-two-cents/3767 .
The text was updated successfully, but these errors were encountered: