-
Notifications
You must be signed in to change notification settings - Fork 13.3k
SIGTRAP in drop glue when slice literal initialization panics #30018
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: