-
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
rustc segfaults if out-of-disk is encountered inside LLVM #122089
Comments
Neither adding |
Ah. That's because this then detects all backtraces as "inside llvm" because the checking function's name contains "llvm". I'll change the function name in the description. |
Ah I think I see what you meant actually. A debug build of the I wouldn't be surprised if a debug build adds enough slowness around |
I was just wondering if |
I speculate it's because of multiple occurrences of fatal errors. |
It doesn't block that PR, it's not moving just yet because I'm trying to write a check for int to reference transmutes. |
In a recent crater run I found a suspicious number of segfaults from rustc (search all crater logs for
SIGSEGV: invalid memory reference
): #121282 (comment). Examples:https://crater-reports.s3.amazonaws.com/pr-121282/try%23d073071d77ce0f93b4fd8cc567a1e2b9e1b22126%2Brustflags=-Copt-level=3/gh/tgnottingham.valgrind-ebpf-rodata-bug/log.txt
https://crater-reports.s3.amazonaws.com/pr-121282/try%23d073071d77ce0f93b4fd8cc567a1e2b9e1b22126%2Brustflags=-Copt-level=3/gh/wyatt-herkamp.auto_project/log.txt
https://crater-reports.s3.amazonaws.com/pr-121282/try%23d073071d77ce0f93b4fd8cc567a1e2b9e1b22126%2Brustflags=-Copt-level=3/gh/wrsturgeon.gamecontroller3-nix/log.txt
It's a bit suspicious that these all appear after a cascade of
LLVM ERROR
output. I've modified the test rig I posted here to test this situation: #119510new evil write impl
Then build any sizable project with that
write
impl:and you should be greeted with a huge pile of errors:
output from building exa
gdb reports this backtrace from the core dump:
This looks like allocator corruption from state corruption (a data race?) in an atexit handler.
Note that though I found this in a yet-to-be-merged PR, this trivially reproduces on stable.
The text was updated successfully, but these errors were encountered: