Skip to content
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

Closed
eefriedman opened this issue Jul 28, 2016 · 7 comments
Closed
Labels
A-diagnostics Area: Messages for errors, warnings, and lints

Comments

@eefriedman
Copy link
Contributor

eefriedman commented Jul 28, 2016

struct C;
impl Drop for C {
    fn drop(&mut self) {}
}
fn main() {
    {
        let mut c = C;
        unsafe { *(&mut c as *mut C as *mut u8) = 1; }
    }
    println!("Hello World");
}

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 .

@nagisa
Copy link
Member

nagisa commented Jul 28, 2016

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

let llfn = cx.ccx().get_intrinsic(&("llvm.debugtrap"));

@nagisa
Copy link
Member

nagisa commented Jul 28, 2016

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.

@steveklabnik steveklabnik added the A-diagnostics Area: Messages for errors, warnings, and lints label Jul 28, 2016
@DemiMarie
Copy link
Contributor

@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.

@arielb1
Copy link
Contributor

arielb1 commented Jul 29, 2016

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 SIGILL).

@MagaTailor
Copy link

Indeed, I'm getting a SIGILL here (debug only obviously), similar, but unrelated, to #34427.

@DemiMarie
Copy link
Contributor

Would Valgrind detect this? If not, I suspect that Rust needs ASan and UBSan support.

@arielb1
Copy link
Contributor

arielb1 commented Sep 15, 2016

filling drop is now a thing of the past. You can't corrupt drop flags without hardcore stack corruption now.

@arielb1 arielb1 closed this as completed Sep 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints
Projects
None yet
Development

No branches or pull requests

6 participants