See issues on rustc here: - https://github.com/rust-lang/rust/issues/31328 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812825 They worked around it by forcing the test to be statically compiled. However, there may still be an issue, and we don't know what is causing the segfault. Reproducible: Always Steps to Reproduce: 1. On an i686 machine, download rust nightly from before 2016-02-17, e.g. https://static.rust-lang.org/dist/2016-02-14/rustc-nightly-src.tar.gz 2. Build it and run the tests. 3. Watch down-with-thread-dtors.stage2 fail. Actual Results: ==6449== Can't extend stack to 0x4bb9880 during signal delivery for thread 2: ==6449== no stack segment ==6449== ==6449== Process terminating with default action of signal 11 (SIGSEGV) ==6449== Access not within mapped region at address 0x4BB9880 ==6449== at 0x10936F: Bar::drop.4321::h008b747fa83237a8 (in /home/nodakai/src/rust-HEAD/x86_64-unknown-linux-gnu/test/run-pass-valgrind/down-with-thread-dtors.stage2-i686-unknown-linux-gnu) ==6449== by 0x4C42A3B: __call_tls_dtors (in /lib/i386-linux-gnu/libc-2.21.so) ==6449== by 0x4BDFF78: start_thread (pthread_create.c:343) ==6449== by 0x4CE7C5D: clone (in /lib/i386-linux-gnu/libc-2.21.so) ==6449== If you believe this happened as a result of a stack ==6449== overflow in your program's main thread (unlikely but ==6449== possible), you can try to increase the size of the ==6449== main thread stack using the --main-stacksize= flag. ==6449== The main thread stack size used in this run was 8388608. ==6449== 152 bytes in 1 blocks are possibly lost in loss record 6 of 7 ==6449== at 0x482E118: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==6449== by 0x4010B06: allocate_dtv (in /lib/i386-linux-gnu/ld-2.21.so) ==6449== by 0x40114EB: _dl_allocate_tls (in /lib/i386-linux-gnu/ld-2.21.so) ==6449== by 0x4BE07B4: allocate_stack (allocatestack.c:587) ==6449== by 0x4BE07B4: pthread_create@@GLIBC_2.1 (pthread_create.c:537) ==6449== by 0x48E1BB6: sys::thread::Thread::new::h2db9ab5f5bc239c37ux (in /home/nodakai/src/rust-HEAD/x86_64-unknown-linux-gnu/stage2/lib/rustlib/i686-unknown-linux-gnu/lib/libstd-db5a760f.so) ==6449== by 0x1096D0: main::h225df9f85db6309aGfa (in /home/nodakai/src/rust-HEAD/x86_64-unknown-linux-gnu/test/run-pass-valgrind/down-with-thread-dtors.stage2-i686-unknown-linux-gnu) ==6449== by 0x48F2ECA: sys_common::unwind::try::try_fn::h17787564768047935801 (in /home/nodakai/src/rust-HEAD/x86_64-unknown-linux-gnu/stage2/lib/rustlib/i686-unknown-linux-gnu/lib/libstd-db5a760f.so) ==6449== by 0x48E9DE7: __rust_try (in /home/nodakai/src/rust-HEAD/x86_64-unknown-linux-gnu/stage2/lib/rustlib/i686-unknown-linux-gnu/lib/libstd-db5a760f.so) ==6449== by 0x48F29CF: rt::lang_start::hed30906487dce269Wxy (in /home/nodakai/src/rust-HEAD/x86_64-unknown-linux-gnu/stage2/lib/rustlib/i686-unknown-linux-gnu/lib/libstd-db5a760f.so) ==6449== by 0x10A57D: main (in /home/nodakai/src/rust-HEAD/x86_64-unknown-linux-gnu/test/run-pass-valgrind/down-with-thread-dtors.stage2-i686-unknown-linux-gnu) ==6449== Expected Results: All tests pass There is a proc-mem from vgdb map here: https://paste.debian.net/394367/
Hasn't it told you exactly what cause the fault? You ran out of stack space...
We don't think that's the real reason. I don't know how to analyse such things but another Debian maintainer looked through the proc-mem map that I linked above, and had this to say: 15:48:15 <kaeso> infinity0: it seems to me it still has some space to grow the stack in slot 26, even though I don't understand why it's trying to do it there 15:49:41 <kaeso> infinity0: I think valgrind is getting to confuse the same way and won't let the stack grow there
What you're missing is that valgrind imposes it's own limit of 8Mb on the stack, which you have clearly hit given the size it reported. Just looking at the memory map won't help you.
At least I thought it did, because I remember it being discussed recently, bit I can't find it right now...
Well, I had already tried setting --main-stacksize (as the error message suggests) very high all the way until other tests started failing because the "stack was too big", and the segfault issue persisted. I know that this flag doesn't change the stack size of new threads, however I read somewhere else that the latter is outside of valgrind's control so that's why there is no such flag - but then this also implies that shouldn't be the cause of this issue. (Or is this wrong? I'm just repeating what I remember reading, I don't really understand valgrind.) Does your theory explain why everything's OK on amd64, and is also OK on i686 when we statically link the test executable (the current "fix" commited to rust)?
Seeing the first 2 lines of output: ==6449== Can't extend stack to 0x4bb9880 during signal delivery for thread 2: ==6449== no stack segment it might be worth trying with --vex-iropt-register-updates=allregs-at-each-insn just in case your test case does special things with signals.
(In reply to infinity0 from comment #5) Greetings, Rustacean::infinity0. Is this bug still a problem for the Rust devs? If yes, are there up to date STRs? On the whole I am unhappy when Valgrind fails, for unclear reasons, to run a program that works natively. So if there's an easy fix, it would be nice to find it.