-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
SIGTRAP in drop glue when slice literal initialization panics #30018
Comments
Popped up in broken tests in one of my crates: kornelski/rust-security-framework@8ab48c2 |
triage: I-nominated probably good to have crashes like this categorized at least |
It does appear to have been present since 1.0 at least, BTW. |
@alexcrichton added back I-nominated, assuming that the removal was unintentional. |
@pnkfelix notes that this is likely a debug flag, and probably only occurs if debug assertions are enabled. |
triage: P-medium |
Yeah, when compiling with optimizations, it won't hit this signal but continues on and behavior depends on the specific case. The minimized example exits without issue, but the test case I had in my crate segfaults. |
I think I know why this happens; it is probably related to how somewhat sloppy handling of the drop flags on scratch/temporary values in other contexts (see e.g. #30530). |
…st-lang#30530, rust-lang#30822. Note that the test for rust-lang#30822 is folded into the test for rust-lang#30530 (but the file name mentions only 30530).
…r-issue-30530, r=dotdash Put back alloca zeroing for issues rust-lang#29092, rust-lang#30018, rust-lang#30530; inject zeroing for rust-lang#30822. ---- Background context: `fn alloca_zeroed` was removed in PR rust-lang#22969, so we haven't been "zero'ing" (\*) the alloca's since at least that point, but the logic behind that PR seems sound, so its not entirely obvious how *long* the underlying bug has actually been present. In other words, I have not yet done a survey to see when the new `alloc_ty` and `lvalue_scratch_datum` calls were introduced that should have had "zero'ing" the alloca's. ---- I first fixed rust-lang#30018, then decided to do a survey of `alloc_ty` calls to see if they needed similar treatment, which quickly led to a rediscovery of rust-lang#30530. While making the regression test for the latter, I discovered rust-lang#30822, which is a slightly different bug (in terms of where the "zero'ing" needs to go), but still relevant. I haven't finished the aforementioned survey of `fn alloc_ty` calls, but I decided I wanted to get this up for review in its current state (namely to see if my attempt to force developers to include a justification for passing `Uninit` can possibly fly, or if I should abandon that path of action). ---- (*): I am putting quotation marks around "zero'ing" because we no longer use zero as our "dropped" marker value. Fix rust-lang#29092 Fix rust-lang#30018 Fix rust-lang#30530 Fix rust-lang#30822
Backtrace:
The text was updated successfully, but these errors were encountered: