Compiler SIGSEGV When Compiling hartex-discord-worker
#115156
Comments
rustbot
added
the
needs-triage
|
Shower thought: could this have happened during LLVM code generaiton? There are a lot of libLLVM frames in the segfault "backtrace" thing, |
|
Duplicate of #115113 (probably) |
tmiasko
added
A-LLVM
|
Not a reproducer for LLVM crash, but demonstrates dubious debuginfo codegen: #![feature(decl_macro)]
macro a() {{{ let _x = [0u64; 4]; }}}
macro b() {{{ a!(); a!(); a!(); }}}
pub fn main() {
b!();
}With MIR: fn main() -> () {
let mut _0: ();
let _1: [u64; 4];
let _2: [u64; 4];
let _3: [u64; 4];
scope 1 {
debug _x => _1;
}
scope 2 {
debug _x => _2;
}
scope 3 {
debug _x => _3;
}
bb0: {
_1 = [const 0_u64; 4];
_2 = [const 0_u64; 4];
_3 = [const 0_u64; 4];
return;
}
}Compiled with ; a::main
; Function Attrs: nonlazybind uwtable
define void @_ZN1a4main17hf6d320809b93b618E() unnamed_addr #0 !dbg !7 {
start:
%_x2 = alloca [4 x i64], align 8
%_x1 = alloca [4 x i64], align 8
%_x = alloca [4 x i64], align 8
call void @llvm.dbg.declare(metadata ptr %_x, metadata !13, metadata !DIExpression()), !dbg !20
call void @llvm.dbg.declare(metadata ptr %_x1, metadata !13, metadata !DIExpression()), !dbg !20
call void @llvm.dbg.declare(metadata ptr %_x2, metadata !13, metadata !DIExpression()), !dbg !20 |
This comment was marked as off-topic.
This comment was marked as off-topic.
rustbot
removed
the
I-prioritize
|
@apiraino as indicated in #115156 (comment), this is a distinct issue that will be fixed by neither #115139 nor #115140. |
|
@tmiasko sorry for my confusing comment and thanks for the correction. By reading your comment I didn't clearly understand it was contradicting the previous one. |
|
The fix PR has not been merged, but for some reason rustc did not segfault on CI as of today. Metadata: |
|
Ah, in that case I would also add that building helix editor with debuginfo=2 quite reliably reproduced the crash for me: $ git clone https://github.com/helix-editor/helix
$ cd helix
$ git reset --hard c9694f680f97823ac9b893239a78bf45bfee0403
$ env RUSTFLAGS='-g' cargo +nightly build --releaseAs far change itself is concerned, my impression is that implementing this would require an additional scope identifiers that would be preserved after MIR inlining. |
|
When I repro this bug, what I'm seeing in the IR is: Then, later (in the frame setup of the same function): So LLVM is complaining about having two
I think this would be a reasonable workaround, as it would allow separate debug variable declarations instead of trying to de-dupe those as well. However, I don't know enough about LLVM to know if that is a hacky workaround or the correct way to generate this code (from my experiments with Clang, it seems to de-dupe debug variable declarations). |
Use the same DISubprogram for each instance of the same inlined function within a caller
# Issue Details:
The call to `panic` within a function like `Option::unwrap` is translated to LLVM as a `tail call` (as it will never return), when multiple calls to the same function like this are inlined LLVM will notice the common `tail call` block (i.e., loading the same panic string + location info and then calling `panic`) and merge them together.
When merging these instructions together, LLVM will also attempt to merge the debug locations as well, but this fails (i.e., debug info is dropped) as Rust emits a new `DISubprogram` at each inline site thus LLVM doesn't recognize that these are actually the same function and so thinks that there isn't a common debug location.
As an example of this, consider the following program:
```rust
#[no_mangle]
fn add_numbers(x: &Option<i32>, y: &Option<i32>) -> i32 {
let x1 = x.unwrap();
let y1 = y.unwrap();
x1 + y1
}
```
When building for x86_64 Windows using 1.72 it generates (note the lack of `.cv_loc` before the call to `panic`, thus it will be attributed to the same line at the `addq` instruction):
```llvm
.cv_loc 0 1 3 0 # src\lib.rs:3:0
addq $40, %rsp
retq
leaq .Lalloc_f570dea0a53168780ce9a91e67646421(%rip), %rcx
leaq .Lalloc_629ace53b7e5b76aaa810d549cc84ea3(%rip), %r8
movl $43, %edx
callq _ZN4core9panicking5panic17h12e60b9063f6dee8E
int3
```
# Fix Details:
Cache the `DISubprogram` emitted for each inlined function instance within a caller so that this can be reused if that instance is encountered again.
Ideally, we would also deduplicate child scopes and variables, however my attempt to do that with rust-lang#114643 resulted in asserts when building for Linux (rust-lang#115156) which would require some deep changes to Rust to fix (rust-lang#115455).
Instead, when using an inlined function as a debug scope, we will also create a new child scope such that subsequent child scopes and variables do not collide (from LLVM's perspective).
After this change the above assembly now (with <https://reviews.llvm.org/D159226> as well) shows the `panic!` was inlined from `unwrap` in `option.rs` at line 935 into the current function in `lib.rs` at line 0 (line 0 is emitted since it is ambiguous which line to use as there were two inline sites that lead to this same code):
```llvm
.cv_loc 0 1 3 0 # src\lib.rs:3:0
addq $40, %rsp
retq
.cv_inline_site_id 6 within 0 inlined_at 1 0 0
.cv_loc 6 2 935 0 # library\core\src\option.rs:935:0
leaq .Lalloc_5f55955de67e57c79064b537689facea(%rip), %rcx
leaq .Lalloc_e741d4de8cb5801e1fd7a6c6795c1559(%rip), %r8
movl $43, %edx
callq _ZN4core9panicking5panic17hde1558f32d5b1c04E
int3
```
My current attempts to compile my project,
discord-frontend, fails with thehartex-discord-workercrate (the following output comes from GitHub Actions CI):I expected to see this happen: project to be compiled successfully
Instead, this happened: the compiler exited with
SIGSEGV, as shown from output above.Meta
rustc --version --verbose:P.S. I have tested this on my local Windows machine, with the following version information, in which the compilation works fine:
It seems like the segfault is only reproducible on Linux, but not Windows (I have personally not tested this on macOS, as I don't have an Apple machine at my disposal).
The text was updated successfully, but these errors were encountered: