[Pkg-rust-maintainers] Bug#865549: cargo still segfaults / rustc still FTBFS with the newest fixed kernel

[Ximin Luo]

Ben Hutchings:
> On Thu, 2017-06-29 at 17:45 +0000, Ximin Luo wrote:
>> Ximin Luo:
>>> [..]
>>>
>>> The segfault occurs on various commands at different frequencies and after 
>>> differing amounts of time (but all less than a few seconds). The stack traces 
>>> are all different too. [..]
>>
>> With some help from arielby from #rust-internals, we noticed that the
>> stack getting allocated was always 192KB even though `ulimit -s` says
>> 8192 (i.e. 8MB),
> 
> That's normal.
> 
>> and when the program tries to grow beyond this, is when the segfaults
>> occur. Hope that's useful.
> 
> That's obviously not.  A page fault below the stack mapping and not too
> far below the stack pointer should cause the mapping to expand, up to
> the limit, without the process having to do anything about it.
> 
> The shell ulimit command, and the underlying setrlimit(2) system call,
> set the limit for expansion of the stack mapping.  Expansion is also
> restricted by the requirement of a gap between the stack and the next
> mapping below, but so long as the size limit is not 'unlimited' this
> *should* make no difference.  The gap used to be 1 page and is now
> configurable but defaults to 256 pages.
> 
> The stack gap used to be included in the range shown in /proc/*/maps
> and was counted toward the stack limit.  The first version of the fix
> did not change that, so it effectively reduced all existing limits by
> 255 pages.  The second version of the fix excludes the stack gap from
> both.
> 
> This expanding behaviour normally only applies to the initial thread's
> stack mapping, which is allocated automatically by execve(2).  For new
> threads created using clone(2) the caller usually sets up a fixed size
> stack mapping.
> 
> Hopefully that explanation can help you and the Rust developers
> identify what's upsetting Rust, and I can then try to get the kernel
> behaviour further refined to avoid doing so.
> 

If you were suggesting that perhaps non-main threads were being created too small, I'm fairly sure that's not the case (or at least, not relevant here) as all of the many different stack traces I've seen have had main() at the bottom. But I'll pass this point onto the Rust developer when he gets back online and see if we can figure out any more details.

> [...]
>> Also, I earlier stated that this could be worked around by disabling
>> ASLR (which gdb does implicitly, so we had to re-enable it). This was
>> true on a deb8u1 kernel, but seems no longer to be true on the newer
>> deb8u2 kernels - i.e. now when disabling ASLR I still see the
>> segfaults. :(
>>
>> [..]
> 
> Do you know how much stack space this function needs?  Can you get the
> page fault address?  (I don't remember how to do that in gdb.)
> 

The segfaults occur in many different places, depending on the args I run cargo with and whether ASLR is enabled, so I don't think it's the fault of any particular function. As for page fault addresses:

infinity0 at page:~/rust-1.18.0-powerpc64le-unknown-linux-gnu$ gdb -d ~/glibc-2.19/debian/ -d ~/glibc-2.19/malloc -q "$@" -ex 'run install regex' cargo/bin/cargo
[..]
    Updating registry `https://github.com/rust-lang/crates.io-index`

Program received signal SIGSEGV, Segmentation fault.
0x00003fffb7e7b0b8 in make_request (fd=4, pid=<optimized out>) at ../sysdeps/unix/sysv/linux/check_pf.c:140
warning: Source file is more recent than executable.
140	    buf = alloca (buf_size);
(gdb) bt
[..]
#33 std::rt::lang_start () at /checkout/src/libstd/rt.rs:57
#34 0x00000000201185f8 in main ()
[..]
(gdb) shell command grep stack /proc/4416/maps
3ffffffd0000-400000000000 rw-p 00000000 00:00 0                          [stack]
(gdb) p $_siginfo._sifields._sigfault.si_addr
$1 = (void *) 0x3ffffffc9130

^ That's the address causing the page fault. It's about 28K off the end of the stack, which seems implausibly high, but I don't know what to make of that.

Another example, with ASLR enabled:

infinity0 at page:~/rust-1.18.0-powerpc64le-unknown-linux-gnu$ ./reproduce-bug.sh  -ex 'set disable-randomization off'
[..]
Program received signal SIGSEGV, Segmentation fault.
0x0000000047d0a4c0 in cargo::ops::cargo_install::install::h8f2d4dce705ec3a6 ()
(gdb) bt
[..]
#10 std::rt::lang_start () at /checkout/src/libstd/rt.rs:57
#11 0x0000000047b885f8 in main ()
[..]
(gdb) shell command grep stack /proc/4445/maps
3fffdbf30000-3fffdbf60000 rw-p 00000000 00:00 0                          [stack]
(gdb) p $_siginfo._sifields._sigfault.si_addr
$1 = (void *) 0x3fffdbf2f260

^ "Only" 3K off the end this time.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git