Segfault in rustup-init on OS X 10.10.5/10.11.6

[qdot]

rustup-init (whatever is current as of 2016-08-22) segfaulted failed on 2 different mbp models, both running 10.10.5.

lldb output:

23Process 1740 launched: '/Users/qdot/Downloads/rustup-init' (x86_64)
23Process 1740 stopped
* thread #1: tid = 0x2890, 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176
rustup-init`je_huge_dalloc:
->  0x10024cbf0 <+176>: movq   (%r8,%rdx,8), %r14
    0x10024cbf4 <+180>: movq   (%r14), %rbx
    0x10024cbf7 <+183>: movq   %rbx, -0x30(%rbp)
    0x10024cbfb <+187>: movq   %rsi, %rdi
(lldb) bt
* thread #1: tid = 0x2890, 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176
    frame #1: 0x000000010023624f rustup-init`je_sdallocx + 1087
    frame #2: 0x000000010002cbd2 rustup-init`rustup_init::self_update::install::h7237ab7ae2a2da9d + 5154
    frame #3: 0x000000010003df21 rustup-init`rustup_init::main::h4ad9acfe630cd1dd + 5857
    frame #4: 0x0000000100230beb rustup-init`__rust_maybe_catch_panic + 27
    frame #5: 0x000000010022f2ff rustup-init`std::rt::lang_start::h352a66f5026f54bd + 399
    frame #6: 0x0000000100001484 rustup-init`start + 52
(lldb)

[ashrithr]

Same here on mbp running 10.11.6.

curl https://sh.rustup.rs -sSf | sh
info: downloading installer
sh: line 250: 17140 Segmentation fault: 11  "$@"
rustup: command failed: /var/folders/5z/rggs791s4ml6fhs4bxzg7k1w0000gn/T/tmp.dBwAW49U/rustup-init

lldb output:

(lldb) run
Process 17188 launched: './rustup-init' (x86_64)
Process 17188 stopped
* thread #1: tid = 0x137e81, 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176
rustup-init`je_huge_dalloc:
->  0x10024cbf0 <+176>: movq   (%r8,%rdx,8), %r14
    0x10024cbf4 <+180>: movq   (%r14), %rbx
    0x10024cbf7 <+183>: movq   %rbx, -0x30(%rbp)
    0x10024cbfb <+187>: movq   %rsi, %rdi
(lldb) bt
* thread #1: tid = 0x137e81, 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176
    frame #1: 0x000000010023624f rustup-init`je_sdallocx + 1087
    frame #2: 0x000000010002cbd2 rustup-init`rustup_init::self_update::install::h7237ab7ae2a2da9d + 5154
    frame #3: 0x000000010003df21 rustup-init`rustup_init::main::h4ad9acfe630cd1dd + 5857
    frame #4: 0x0000000100230beb rustup-init`__rust_maybe_catch_panic + 27
    frame #5: 0x000000010022f2ff rustup-init`std::rt::lang_start::h352a66f5026f54bd + 399
    frame #6: 0x0000000100001484 rustup-init`start + 52

[qdot]

Updated description to reflect more broken versions.

[defuz]

I have the same error on 10.12 (Sierra beta). My report:

https://gist.github.com/defuz/5d3db5293834c387ea01e9e203ff3f39

[JoeHegarty]

I'm running into the same issue on multiple MBPs with 10.11 and 10.12.

[Diggsey]

I don't have a MBP to test this on, but could you try setting the environment variable RUSTUP_INIT_SKIP_SUDO_CHECK to be yes before running rustup-init and see if that fixes the problem?

[JoeHegarty]

Yes @Diggsey. That resolves the issue for me.

[brson]

Ugly bug. Nice find @Diggsey. We'll try to get a fix out asap.

[brson]

I can't reproduce on 10.8.5.

[brson]

Was anybody who is affected by this able to install rustup successfully on OS X 10.10+ recently? This code has been in place since late July.

The bug is in this block of code. I've read through it several times, and while the transmute could be eliminated and there might be sketchy lifetimes around the CStr, I don't see the error.

For now I'm going to disable this function on macOS, but I'd appreciate help from anyone that can reproduce it. Maybe just some println debugging to see what's going wrong.

[brson]

OK, I found a box to reproduce it on.

[brson]

Seems like it only happens when built with the nightly compiler, not stable, so that would explain why it hasn't turned up before. We recently switch toolchains.

[brson]

Fix is landed. Thanks @alexcrichton. Reopening until deployed.

[brson]

Fixed.