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

Activity

1. RalfJung commented on Aug 16, 2018

   

   RalfJung

   on Aug 16, 2018

   MemberAuthor

   More actions

   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"
   
2. RalfJung commented on Aug 17, 2018

   

   RalfJung

   on Aug 17, 2018

   Last edited by RalfJung

   MemberAuthor

   More actions

   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.
3. eddyb commented on Aug 17, 2018

   

   eddyb

   on Aug 17, 2018

   Last edited by eddyb

   Contributor

   More actions

   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).
4. alexcrichton commented on Aug 20, 2018

   

   alexcrichton

   on Aug 20, 2018

   Member

   More actions

   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
5. pnkfelix

   added

   T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.

   on Sep 14, 2018
6. pnkfelix commented on Sep 14, 2018

   

   pnkfelix

   on Sep 14, 2018

   Contributor

   More actions

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

   added

   C-bugCategory: This is a bug.Category: This is a bug.

   on Sep 14, 2018
8. Enselic commented on Oct 12, 2023

   

   Enselic

   on Oct 12, 2023

   Member

   More actions

   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.)
9. RalfJung commented on Oct 12, 2023

   

   RalfJung

   on Oct 12, 2023

   MemberAuthor

   More actions

   I haven't seen this in a long time.
10. Enselic commented on Nov 4, 2024

    

    Enselic

    on Nov 4, 2024

    Member

    More actions

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

    closed this as not plannedon Nov 4, 2024