rustc (segmentation fault)

[tejinderss]

Ran this curl -sSf https://static.rust-lang.org/rustup.sh | sh

and then tries to start rustc

gave:

Segmentation Fault (core dumped)

[sunilmut]

@tejinderss Thanks for reporting this. We are aware of this and have an internal bug tracking this. Unfortunately, there are no other updates at this moment.

[benpye]

I have also run into this unfortunate issue, attached is a stack trace.

(gdb) r
Starting program: /home/ben/.multirust/toolchains/stable/bin/rustc
warning: Error disabling address space randomization: Success
warning: linux_ptrace_test_ret_to_nx: PTRACE_KILL waitpid returned -1: Interrupted system call

Program received signal SIGSEGV, Segmentation fault.
open_verify (name=name@entry=0x7ff5fffeecb0 "/home/ben/.multirust/toolchains/stable/bin/../lib/libstd-4fda350b.so",
    fbp=fbp@entry=0x7ff5fffeeee8, loader=loader@entry=0x7ff5ffe241c8, whatcode=whatcode@entry=4,
    found_other_class=found_other_class@entry=0x7ff5fffeeed0, free_name=false) at dl-load.c:2098
2098    dl-load.c: No such file or directory.
(gdb) bt
#0  open_verify (
    name=name@entry=0x7ff5fffeecb0 "/home/ben/.multirust/toolchains/stable/bin/../lib/libstd-4fda350b.so",
    fbp=fbp@entry=0x7ff5fffeeee8, loader=loader@entry=0x7ff5ffe241c8, whatcode=whatcode@entry=4,
    found_other_class=found_other_class@entry=0x7ff5fffeeed0, free_name=false) at dl-load.c:2098
#1  0x00007ff5ffc061cf in open_path (name=name@entry=0x80004da "libstd-4fda350b.so", namelen=namelen@entry=19,
    secure=secure@entry=0, sps=sps@entry=0x7ff5ffe24570, realname=realname@entry=0x7ff5fffeeed8,
    fbp=fbp@entry=0x7ff5fffeeee8, loader=loader@entry=0x7ff5ffe241c8, whatcode=whatcode@entry=4,
    found_other_class=found_other_class@entry=0x7ff5fffeeed0) at dl-load.c:2216
#2  0x00007ff5ffc08f91 in _dl_map_object (loader=0x7ff5ffe241c8, name=0x80004da "libstd-4fda350b.so", type=1,
    trace_mode=0, mode=<optimized out>, nsid=<optimized out>) at dl-load.c:2456
#3  0x00007ff5ffc0d602 in openaux (a=a@entry=0x7ff5fffef4d8) at dl-deps.c:63
#4  0x00007ff5ffc0fff4 in _dl_catch_error (objname=objname@entry=0x7ff5fffef4d0,
    errstring=errstring@entry=0x7ff5fffef4c8, mallocedp=mallocedp@entry=0x7ff5fffef4c0,
    operate=operate@entry=0x7ff5ffc0d5d0 <openaux>, args=args@entry=0x7ff5fffef4d8) at dl-error.c:187
#5  0x00007ff5ffc0dd05 in _dl_map_object_deps (map=map@entry=0x7ff5ffe241c8, preloads=<optimized out>,
    npreloads=npreloads@entry=0, trace_mode=trace_mode@entry=0, open_mode=open_mode@entry=0) at dl-deps.c:254
#6  0x00007ff5ffc0315d in dl_main (phdr=<optimized out>, phdr@entry=0x8000040, phnum=<optimized out>, phnum@entry=8,
    user_entry=user_entry@entry=0x7ff5fffef668, auxv=<optimized out>) at rtld.c:1742
#7  0x00007ff5ffc17565 in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7ff5fffef750,
    dl_main=dl_main@entry=0x7ff5ffc01910 <dl_main>) at ../elf/dl-sysdep.c:249
#8  0x00007ff5ffc04cf8 in _dl_start_final (arg=0x7ff5fffef750) at rtld.c:332
#9  _dl_start (arg=0x7ff5fffef750) at rtld.c:558
#10 0x00007ff5ffc012d8 in _start () from /lib64/ld-linux-x86-64.so.2
#11 0x0000000000000001 in ?? ()
#12 0x00007ff5fffef948 in ?? ()
#13 0x0000000000000000 in ?? ()
(gdb)

I'm curious what causes rustc to fail in this way?

[benpye]

Investigating this somewhat seems to reveal that it's the .note.rustc section in the dynamic libraries causing the issue. rust-lang/rust#26764 documents the problem better, stripping the problematic section does appear to get the execution further, I'm going to try updating their patch to see if it resolves the issue.

[sunilmut]

@benpye Awesome debugging here. Yes, WSL currently does has some limitations around the initial stack size, which we have plans to address. Curious to know how rustc behaves with the patch.

[benpye]

@sunilmut Yeah, seems it is an issue with the stack size as mentioned in that issue. Building rust with the patch (updated for current master) results in a functional build of rust under WSL. I don't suppose there is any way to increase the initial stack size or is this something we're going to have to wait for?

[stehufntdev]

Recent internal builds fixed the reporting of the stack ulimit and bumped the initial thread stack to 8MB. The change should be coming to insider builds soon.

[benpye]

That's great to know, look forward to seeing this change going forward!

On Tue, 17 May 2016, 22:06 stehufntdev, notifications@github.com wrote:

Recent internal builds fixed the reporting of the stack ulimit and bumped
the initial thread stack to 8MB. The change should be coming to insider
builds soon.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#258 (comment)

[russalex]

Just built and ran a quick hello world app in Rust.

Fixes are in build 14361.