error: rustc interrupted by SIGSEGV -- i686 OOM #121305
Labels
A-LLVM
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
C-bug
Category: This is a bug.
I-crash
Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
O-x86_32
Target: x86 processors, 32 bit (like i686-*)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
ctron
added
C-bug
rustbot
added
the
needs-triage
|
To my understanding this should be Rust |
matthiaskrgr
added
the
A-LLVM
saethlin
added
I-crash
jieyouxu
added
the
E-needs-mcve
|
I think this is "just" an OOM situation. Fedora builds with full debuginfo by default, and this package is configured for fat LTO as well, which will all get quite heavy. When I tried to reproduce this with the It completed when I turned off debuginfo though. With Fedora's toolchain, I can reproduce your SIGSEGV in LLVM, but it also completes the build when debuginfo is off. My guess is that it is also hitting an allocation failure, but perhaps in a place that doesn't properly check the pointer before trying to use it. |
|
With the rustup toolchain, it's running out of memory in LLVM's With the Fedora toolchain, it's running out of memory in LLVM's |
jieyouxu
removed
the
E-needs-mcve
|
I encontered this when compiling a big proprietary project to --target=i686-unknown-linux-musl using nightly-2024-03-01 on a x86_64 host |
|
@Librazy with an x86_64 host and a different backtrace, I doubt that yours has the same root cause. I suggest filing a separate issue -- but it's going to be hard for anyone to help if they can't reproduce it, since your code is proprietary. |
cuviper
changed the title
This was referenced Mar 14, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 16, 2024
Register LLVM handlers for bad-alloc / OOM LLVM's default bad-alloc handler may throw if exceptions are enabled, and `operator new` isn't hooked at all by default. Now we register our own handler that prints a message similar to fatal errors, then aborts. We also call the function that registers the C++ `std::new_handler`. Fixes rust-lang#121305 Cc llvm/llvm-project#85281 r? `@nikic`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Mar 17, 2024
Register LLVM handlers for bad-alloc / OOM LLVM's default bad-alloc handler may throw if exceptions are enabled, and `operator new` isn't hooked at all by default. Now we register our own handler that prints a message similar to fatal errors, then aborts. We also call the function that registers the C++ `std::new_handler`. Fixes rust-lang#121305 Cc llvm/llvm-project#85281 r? `@nikic`
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 17, 2024
Rollup merge of rust-lang#122574 - cuviper:llvm-oom, r=nikic Register LLVM handlers for bad-alloc / OOM LLVM's default bad-alloc handler may throw if exceptions are enabled, and `operator new` isn't hooked at all by default. Now we register our own handler that prints a message similar to fatal errors, then aborts. We also call the function that registers the C++ `std::new_handler`. Fixes rust-lang#121305 Cc llvm/llvm-project#85281 r? ``@nikic``
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Running a build of
trunk, as part of a Koiji (Fedora Build System) job, I get the following for thei686target:Also see: https://kojipkgs.fedoraproject.org//work/tasks/2175/113752175/build.log
The text was updated successfully, but these errors were encountered: