Rust compiler crashes during compilation #66595
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-compiletime
Issue: Problems and improvements with respect to compile times.
I-crash
Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
csmoe
added
the
E-needs-mcve
|
@ethindp any specific commit one should use for the error to reproduce? What OS are you on? Could you please elaborate the steps to reproduce this error a little bit further? e.g.
something like that. |
|
So I did some RUSTC_LOG=debug and it seems, that the rust compiler runs into some kind of error. These are the last lines the debug output will give me: Debug outputand then it just halts... Actually busy waiting (100% CPU load on one core). gdb output: Looking at the assembly, there's are these 4 lines and this loops "forever". Not quiet sure what it's trying to find there. So this is a LLVM bug? |
jonas-schievink
added
A-LLVM
struct HbaCmdTbl {
_prdt_entry: [HbaPrdtEntry; 65535],
}
struct HbaPrdtEntry {
_non_empty: u32
}
fn main() {
let cmdtbl_ptr = std::ptr::null_mut::<HbaCmdTbl>();
let _cmdtbl = unsafe { cmdtbl_ptr.read_volatile() };
}the @rustbot modify labels: -E-needs-mcve edit: In fact I optimized too much I'm afraid. The build succeeds after roughly 6m. I'm not sure if I optimized something away. Should I dig further? |
rustbot
added
E-needs-bisection
jonas-schievink
added
I-compiletime
|
Yeah, I can see how that might take a while, but before I made the
read_volatile changes that didn't take as long as it does now. Now it
taks over an horu and then bails out, which never happened before,
even with the 65535 in there. OS is windows, latest commit.
…On 11/21/19, Marcel Hellwig ***@***.***> wrote:
```rust
struct HbaCmdTbl {
_prdt_entry: [HbaPrdtEntry; 65535],
}
struct HbaPrdtEntry {
_non_empty: u32
}
fn main() {
let cmdtbl_ptr = std::ptr::null_mut::<HbaCmdTbl>();
let _cmdtbl = unsafe { cmdtbl_ptr.read_volatile() };
}
```
the `65535` is taken from the sourcecode, I'm not sure if it can be lowered
any further. but this code triggers the long build time for me.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#66595 (comment)
--
Signed,
Ethin D. Probst
|
|
It looks like LLVM is getting stuck in this loop forever |
|
Any progress on this? |
|
@ethindp filed https://bugs.llvm.org/show_bug.cgi?id=44128 If you want to help out, you can try minimizing the LLVM IR further. |
|
I'm not even remotely familiar with LLVM's inner workings so I don't know how I could help. :( |
|
Just looked at the issue. I could reduce the HbaCmdHeader size considerably if I just made an array without a size, but I don't know if Rustc would then allow me to access arbitrary elements when I read it from memory. |
|
OK, managed to fix the bug by reducing the array item list to 1024. But that'ssignificantly low and doesn't allow me to use every PRDT f I must do that for some reason -- instead I need to batch them, which I suppose isn't necessarily a bad thing. |
|
You probably don't actually want volatile for this; a command table is stored in RAM and is not itself composed of hardware registers, so you don't need to regulate the memory access size. (The same is true for command lists, incidentally.) Instead, you probably want to follow the general pattern:
That works as long as the hardware is not concurrently accessing the memory while you're writing it. (On some architectures you would need a hardware fence instruction or something even more heavyweight at step 2, even if you did use volatile. I guess you don't need it on x86? I don't have experience interacting with hardware on x86 specifically.) If you do need volatile for whatever reason, avoid volatile loads/stores of entire structs at once. Even if the slow compilation issue were fixed, their behavior is not really well-defined and they would likely result in horrible assembly: emitting a separate load/store instruction for every array member instead of using a loop. Instead, you should write the loop yourself and only do volatile loads/stores of one integer at a time. Alternately, you could try That said, it would be nice if rustc and/or LLVM did something saner here. At minimum, rustc could emit a warning for struct-typed volatile accesses. |
|
Sage advice. This hasn't happened to me for a while now, so I'll close this issue. I'll reopen it if I hit this problem again. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
So, I have no idea exactly what I did. I'm writing an operating system and am working on implementing SATA disk IO in my kernel. My code is at https://github.com/ethindp/kernel.
In order to actively read from the disk and get all updates, I use read_volatile() all over the place in my disk IO functions. I have no idea what I did, but now my kernel doesn't build. When I run cargo xbuild, the following happens:
I am running the latest nightly version of rust, rustc 1.41.0-nightly (3e525e3 2019-11-18). The troublesome code is at https://github.com/ethindp/kernel/blob/master/src/drivers/storage/ahci.rs. (Note: the code is very messy right now.)
The text was updated successfully, but these errors were encountered: