Bug 359705

Summary:	memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686
Product:	[Developer tools] valgrind	Reporter:	infinity0
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	REPORTED ---
Severity:	crash	CC:	philippe.waroquiers, tom
Priority:	NOR
Version First Reported In:	3.11.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description infinity0 2016-02-23 14:55:16 UTC

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/

Comment 1 Tom Hughes 2016-02-23 15:05:40 UTC

Hasn't it told you exactly what cause the fault? You ran out of stack space...

Comment 2 infinity0 2016-02-23 15:10:13 UTC

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

Comment 3 Tom Hughes 2016-02-23 16:09:40 UTC

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.

Comment 4 Tom Hughes 2016-02-23 16:13:26 UTC

At least I thought it did, because I remember it being discussed recently, bit I can't find it right now...

Comment 5 infinity0 2016-02-23 16:20:47 UTC

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)?

Comment 6 Philippe Waroquiers 2016-02-27 21:16:50 UTC

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.

Comment 7 Julian Seward 2016-09-13 17:04:06 UTC

(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.