Excessively chaining operators causes a stack overflow in rustc #109648

grind086 · 2023-03-27T03:59:03Z

Excessive (extremely excessive) chaining of operators causes a stack overflow in rustc. In my experimenting I found that this happens with precisely 6115 chained operators in the playground, but it appears to depend on your compilation environment as it took approx. 8000 on my machine. This is easily avoided by splitting the chain (or having an iota of sanity), but I would expect rustc to at least exit gracefully in this case. The code below uses only the Not (!) operator, but at least the Neg (-) operator also works, as does mixing the two (ie -!-!-!).

Playground

Code

fn main() {
    // 6115 chained operators. This should crash the playground. If you remove
    // one or more of the `!`s, it should compile.
    let _ = 
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!true;
}

Local (Windows) Error Message

PS C:\usr\Programming\atira-bevy> cargo run -p bugtest
   Compiling bugtest v0.1.0 (C:\usr\Programming\atira-bevy\apps\bugtest)

thread 'rustc' has overflowed its stack
error: could not compile `bugtest`

Caused by:
  process didn't exit successfully: `rustc --crate-name bugtest --edition=2021 apps\bugtest\src\main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=278 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=62598a30bcc4eedd --out-dir C:\usr\Programming\atira-bevy\target\debug\deps -C incremental=C:\usr\Programming\atira-bevy\target\debug\incremental -L dependency=C:\usr\Programming\atira-bevy\target\debug\deps` (exit code: 0xc00000fd, STATUS_STACK_OVERFLOW)

The playground error message was too long to include here, but a copy can be found in this gist: https://gist.github.com/grind086/703b519f8ff02f32b164d9388abed59b

Meta

The above code was tested in the playground (Debug, Stable, v1.68.1), and a version with 8000 chained operators crashed rustc on my local machine with the following rustc --version --verbose:

rustc 1.67.1 (d5a82bbd2 2023-02-07)
binary: rustc
commit-hash: d5a82bbd26e1ad8b7401f6a718a9c57c96905483
commit-date: 2023-02-07
host: x86_64-pc-windows-msvc
release: 1.67.1
LLVM version: 15.0.6

The text was updated successfully, but these errors were encountered:

workingjubilee · 2023-03-27T04:28:51Z

This is easily avoided by splitting the chain (or having an iota of sanity), but I would expect rustc to at least exit gracefully in this case.

Technically, it did (in the Windows case). The stack overflow was caught by Rust's handler and a message emitted to explain that it had reached stack overflow, instead of simply exiting without remark. This fulfills the letter of your expectation for it to "exit gracefully", but perhaps not your intent. You may wish to clarify how graceful an exit you were hoping for.

It may also be interesting to know if you somehow found a way to use this to cause a stack overflow that did not emit such a message. I am not sure how to interpret the Playground case, honestly, perhaps that qualifies...

Possibly we can manage to avoid overflowing, in any case. I only make such a pedantic note because it can be hard to do better in the face of resource exhaustion.

grind086 · 2023-03-27T05:58:22Z

That's a very fair point. I had actually done the playground one first after someone on Reddit mentioned this, and only tried on windows while writing this. What's weird is that while windows was able to at least give me a general idea of what happened, the playground straight died with a SIGSEGV.

workingjubilee · 2023-03-27T22:43:55Z

The way the Playground one goes, I really wondered if there is something that happens due to libc???

But no, the backtrace is really thousands of lines like this:

#0: 0x00007feac91a72f3 in <rustc_lint::late::LateContextAndPass<rustc_lint::BuiltinCombinedModuleLateLintPass> as rustc_hir::intravisit::Visitor>::visit_expr from "${toolchain_dir}/lib/librustc_driver-${rustc_hash}.so"

workingjubilee · 2023-03-27T23:00:36Z

Ah, I think I see the problem? Sometimes, the address for the function call is the same (it is normalized into a tail-recursive form by LLVM, I am guessing) but when it is not, the offset between lines is like 10KB, sometimes more, which may be enough to jump the guard page entirely.

Disregard that, I was talking nonsense and looking at the wrong values. Stack offset is only a bit over ~1KB but consistently is about ~1KB each time. I think the problem is more just "no attempt to guard the final page" or something like that.

scottmcm · 2023-03-28T00:10:49Z

But no, the backtrace is really thousands of lines like this:

#0: 0x00007feac91a72f3 in <rustc_lint::late::LateContextAndPass<rustc_lint::BuiltinCombinedModuleLateLintPass> as rustc_hir::intravisit::Visitor>::visit_expr from "${toolchain_dir}/lib/librustc_driver-${rustc_hash}.so"

Well, I see this note in https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/stack/fn.ensure_sufficient_stack.html

E.g. almost any call to visit_expr or equivalent can benefit from this.

So that might be a possible fix here (if it's not already called in there).

cuviper · 2023-03-29T17:21:01Z

Diagnosing stack overflows is imperfect on Linux. It's always a SIGSEGV at first, and then we have a signal handler that tries to decide if that fault looks like it hit the stack guard page so we can report a nicer abort. But the kernel manages the guard page in the main thread with its dynamically growing stack, so we have to try to guess where that may be. We should do better with fixed thread stacks -- but I think ensure_sufficient_stack also messes with these heuristics.

workingjubilee · 2023-07-11T05:12:44Z

Example now compiles with... more operators, since #112673 added ensure_sufficient_stack, but still meets its demise and that grody error. Why? Because it hits the parser:

~/rust/rustc/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-87305f62111c37ae.so(+0x10cc993)[0x7fc0dac34993]
/usr/lib/libc.so.6(+0x39ab0)[0x7fc0d97cdab0]
~/rust/rustc/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-87305f62111c37ae.so(_RNvMs2_NtCskQGOrQhHbZu_11rustc_parse6parserNtB5_6Parser4bump+0x22)[0x7fc0e02acaf2]

Note that the signal handler dumps that huge error message on Linux because we install a custom signal handler, which feels like it was written in the Medieval Rust Era or something.

rust/compiler/rustc_driver_impl/src/lib.rs

Lines 1430 to 1494 in fcaf04e

    
           #[cfg(all(unix, any(target_env = "gnu", target_os = "macos")))] 
        
           mod signal_handler { 
        
               extern "C" { 
        
                   fn backtrace_symbols_fd( 
        
                       buffer: *const *mut libc::c_void, 
        
                       size: libc::c_int, 
        
                       fd: libc::c_int, 
        
                   ); 
        
               } 
        
               extern "C" fn print_stack_trace(_: libc::c_int) { 
        
                   const MAX_FRAMES: usize = 256; 
        
                   static mut STACK_TRACE: [*mut libc::c_void; MAX_FRAMES] = 
        
                       [std::ptr::null_mut(); MAX_FRAMES]; 
        
                   unsafe { 
        
                       let depth = libc::backtrace(STACK_TRACE.as_mut_ptr(), MAX_FRAMES as i32); 
        
                       if depth == 0 { 
        
                           return; 
        
                       } 
        
                       backtrace_symbols_fd(STACK_TRACE.as_ptr(), depth, 2); 
        
                   } 
        
               } 
        
               /// When an error signal (such as SIGABRT or SIGSEGV) is delivered to the 
        
               /// process, print a stack trace and then exit. 
        
               pub(super) fn install() { 
        
                   use std::alloc::{alloc, Layout}; 
        
                   unsafe { 
        
                       let alt_stack_size: usize = min_sigstack_size() + 64 * 1024; 
        
                       let mut alt_stack: libc::stack_t = std::mem::zeroed(); 
        
                       alt_stack.ss_sp = alloc(Layout::from_size_align(alt_stack_size, 1).unwrap()).cast(); 
        
                       alt_stack.ss_size = alt_stack_size; 
        
                       libc::sigaltstack(&alt_stack, std::ptr::null_mut()); 
        
                       let mut sa: libc::sigaction = std::mem::zeroed(); 
        
                       sa.sa_sigaction = print_stack_trace as libc::sighandler_t; 
        
                       sa.sa_flags = libc::SA_NODEFER | libc::SA_RESETHAND | libc::SA_ONSTACK; 
        
                       libc::sigemptyset(&mut sa.sa_mask); 
        
                       libc::sigaction(libc::SIGSEGV, &sa, std::ptr::null_mut()); 
        
                   } 
        
               } 
        
               /// Modern kernels on modern hardware can have dynamic signal stack sizes. 
        
               #[cfg(any(target_os = "linux", target_os = "android"))] 
        
               fn min_sigstack_size() -> usize { 
        
                   const AT_MINSIGSTKSZ: core::ffi::c_ulong = 51; 
        
                   let dynamic_sigstksz = unsafe { libc::getauxval(AT_MINSIGSTKSZ) }; 
        
                   // If getauxval couldn't find the entry, it returns 0, 
        
                   // so take the higher of the "constant" and auxval. 
        
                   // This transparently supports older kernels which don't provide AT_MINSIGSTKSZ 
        
                   libc::MINSIGSTKSZ.max(dynamic_sigstksz as _) 
        
               } 
        
               /// Not all OS support hardware where this is needed. 
        
               #[cfg(not(any(target_os = "linux", target_os = "android")))] 
        
               fn min_sigstack_size() -> usize { 
        
                   libc::MINSIGSTKSZ 
        
               } 
        
           } 
        
           #[cfg(not(all(unix, any(target_env = "gnu", target_os = "macos"))))] 
        
           mod signal_handler { 
        
               pub(super) fn install() {} 
        
           }

On Windows, we simply wind up using std's signal handler, which prints that simple message. So I guess to resolve this bug we should improve the error message or simply delete that code.

workingjubilee · 2023-07-11T08:44:45Z

I have opened #113565 to make the error message less cryptic, when that merges I think we should declare victory on this.

workingjubilee · 2023-08-31T01:33:43Z

$ rustc +nightly example.rs
error: rustc interrupted by SIGSEGV, printing backtrace

~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-00c03654e9ecf095.so(+0x3151156)[0x7f6aeee8a156]
/usr/lib/libc.so.6(+0x3e710)[0x7f6aeb945710]
~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-00c03654e9ecf095.so(_RNvMs2_NtCsi4EURiZtIdM_11rustc_parse6parserNtB5_6Parser4bump+0x79)[0x7f6aedac39a9]
~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-00c03654e9ecf095.so(+0x1e72aba)[0x7f6aedbababa]

### cycle encountered after 4 frames with period 6
~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-00c03654e9ecf095.so(+0x1e393de)[0x7f6aedb723de]
~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-00c03654e9ecf095.so(+0x1e72ad3)[0x7f6aedbabad3]
~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-00c03654e9ecf095.so(+0x1e393de)[0x7f6aedb723de]
~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-00c03654e9ecf095.so(+0x1e72ad3)[0x7f6aedbabad3]
~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-00c03654e9ecf095.so(+0x1e393de)[0x7f6aedb723de]
~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-00c03654e9ecf095.so(+0x1e72ad3)[0x7f6aedbabad3]
### recursed 42 times


note: rustc unexpectedly overflowed its stack! this is a bug
note: maximum backtrace depth reached, frames may have been lost
note: we would appreciate a report at https://github.com/rust-lang/rust
Segmentation fault (core dumped)

Victory declared.

grind086 added the C-bug Category: This is a bug. label Mar 27, 2023

workingjubilee added the I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. label Mar 27, 2023

jyn514 added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 27, 2023

workingjubilee linked a pull request Jul 11, 2023 that will close this issue

Make SIGSEGV handler emit nicer backtraces #113565

Merged

bors closed this as completed in #113565 Aug 30, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Excessively chaining operators causes a stack overflow in rustc #109648

Excessively chaining operators causes a stack overflow in rustc #109648

grind086 commented Mar 27, 2023 •

edited

Loading

workingjubilee commented Mar 27, 2023 •

edited

Loading

grind086 commented Mar 27, 2023 •

edited

Loading

workingjubilee commented Mar 27, 2023

workingjubilee commented Mar 27, 2023 •

edited

Loading

scottmcm commented Mar 28, 2023

cuviper commented Mar 29, 2023

workingjubilee commented Jul 11, 2023

workingjubilee commented Jul 11, 2023

workingjubilee commented Aug 31, 2023

Excessively chaining operators causes a stack overflow in rustc #109648

Excessively chaining operators causes a stack overflow in rustc #109648

Comments

grind086 commented Mar 27, 2023 • edited Loading

Meta

workingjubilee commented Mar 27, 2023 • edited Loading

grind086 commented Mar 27, 2023 • edited Loading

workingjubilee commented Mar 27, 2023

workingjubilee commented Mar 27, 2023 • edited Loading

scottmcm commented Mar 28, 2023

cuviper commented Mar 29, 2023

workingjubilee commented Jul 11, 2023

workingjubilee commented Jul 11, 2023

workingjubilee commented Aug 31, 2023

grind086 commented Mar 27, 2023 •

edited

Loading

workingjubilee commented Mar 27, 2023 •

edited

Loading

grind086 commented Mar 27, 2023 •

edited

Loading

workingjubilee commented Mar 27, 2023 •

edited

Loading