stage 1 ui test fails but only once: too big for the current architecture

[RalfJung]

When I run stage 1 ui tests, it sometimes happens that I get a failure in ui/huge-array.rs:

the type [[u8; 1518599999]; 1518600000] is too big for the current architecture

But then, when I rerun the tests, it works. That is rather odd, isn't it?

[RalfJung]

I didn't realize that this is an expected-to-fail test. The problem is that it segfaults:

error: Error: expected failure status (Some(1)) but received status None.
status: signal: 11
command: "/home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/r/src/rust/rustc.2/src/test/ui/huge-array.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/test/ui/huge-array/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/test/ui/huge-array/auxiliary" "-A" "unused"

[RalfJung]

So, @eddyb concluded that this is an LLVM assertion failing.

My guess is that this might be some kind of OOM situation? Working fine when it is the only test running but not when there's many being run in parallel? However, I am not experiencing the thrashing that usually comes with OOM, and I cannot find any trace of the OOM killer in my system log.

[eddyb]

I don't think it's OOM, if you enable LLVM assertions you'll see them spuriously failing on this test.

cc @alexcrichton @pnkfelix @nikomatsakis some of us have seen this before (in compile-fail).

[alexcrichton]

LLVM may be segfaulting due to "oom" or a null pointer dereference. I think that it could be a case that if malloc isn't checked but has a huge size it returns null (no thrashing) and maybe that just causes problems in LLVM? The best way to debug this would probably be a core dump to see where it's faulting in LLVM

[pnkfelix]

(Could this perhaps be caused by async LLVM, which may explain why it is spurious/transient? See also #49928)

[Enselic]

Triage: Is this still happening? If not I think we can close this issue. (I will do so at a later point unless this is reported to still be a problem.)

[RalfJung]

I haven't seen this in a long time.

[Enselic]

Triage: Thanks for the update. Let's close this then.