Repository navigation
Panicking doesn't work on arm-unknown-linux-musleabi #65765
Description
Noticed a regression when running tests with a latest nightly on our xilinx arm machine. This seems to be caused by 5941acd - with Rust 1.38 stable toolchain, panicking works as expected.
With current nightly, when I build a simple program that just panics, I get:
thread 'main' panicked at 'Hello, world!', src/main.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
fatal runtime error: failed to initiate panic, error 9
Aborted
With libunwind debug env vars turned on, I get:
thread 'main' panicked at 'Hello, world!', src/main.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
libunwind: _Unwind_RaiseException(ex_obj=0x53110)
libunwind: __unw_init_local(cursor=0xbec68360, context=0xbec67e28)
libunwind: __unw_get_proc_info(cursor=0xbec68360, &info=0xbec67e00)
libunwind: __unw_get_proc_name(cursor=0xbec68360, &buf=0xbec688fc, bufLen=512)
libunwind: __unw_get_reg(cursor=0xbec68360, regNum=-1, &value=0xbec67dfc)
libunwind: unwind_phase1(ex_ojb=0x53110): pc=0x29a20, start_ip=0x299cc, func=.anonymous., lsda=0x0, personality=0x29f9c
libunwind: unwind_phase1(ex_ojb=0x53110): calling personality function 0x29f9c
libunwind: __unw_get_proc_info(cursor=0xbec68360, &info=0xbec67d7c)
libunwind: _Unwind_GetLanguageSpecificData(context=0xbec68360) => 0x0
libunwind: __unw_step(cursor=0xbec68360)
libunwind: __unw_get_reg(cursor=0xbec68360, regNum=13, &value=0xbec67d68)
libunwind: _Unwind_VRS_Get(context=0xbec68360, regclass=0, reg=13, rep=0, value=0xBEC67DD0, result = 0)
libunwind: _Unwind_VRS_Set(context=0xbec68360, regclass=0, reg=13, rep=0, value=0xBEC67DB0)
libunwind: __unw_set_reg(cursor=0xbec68360, regNum=13, value=0xbec67db0)
libunwind: __unw_get_reg(cursor=0xbec68360, regNum=11, &value=0xbec67d68)
libunwind: _Unwind_VRS_Get(context=0xbec68360, regclass=0, reg=11, rep=0, value=0xBEC68B24, result = 0)
libunwind: _Unwind_VRS_Set(context=0xbec68360, regclass=0, reg=13, rep=0, value=0xBEC68B24)
libunwind: __unw_set_reg(cursor=0xbec68360, regNum=13, value=0xbec68b24)
libunwind: unwind_phase1(ex_ojb=0x53110): personality result 9 start_ip 299cc ehtp 0x406c4 additional 1
fatal runtime error: failed to initiate panic, error 9
Aborted
Some of the addresses above:
0x29a20is inside_Unwind_RaiseException0x299ccis (the start of)_Unwind_RaiseException0x29f9cis__aeabi_unwind_cpp_pr0
Activity
vojtechkral commentedon Oct 27, 2019
I wonder if this might be related: https://reviews.llvm.org/D68972 (revision in SVN). I'll try to test.It wasn't related.
vojtechkral commentedon Oct 30, 2019
I think I probably know what the problem is. The method
getByte()in fileUnwind-EHABI.cppin llvm-project/libwuwind is differentiated based on macro__LITTLE_ENDIAN__. I suspect this macro is for some reason not set when (cross)compiling the toolchain. This makes the unwinding instruction interpretation function_Unwind_VRS_Interpretget the instructions in the wrong order (and also off by one).Edit: Yes, that was the problem. With
__LITTLE_ENDIAN__defined, panicking works again even on nightly. I'll create a PR...pnkfelix commentedon Oct 31, 2019
triage: P-high. Has PR. assigning to @vojtechkral
vojtechkral commentedon Oct 31, 2019
I wonder what other platforms - if any - were affected. I was meaning to test on a Raspberry Pi with gnu libc, but ended up not having the time to do it...
Rollup merge of rust-lang#65972 - braiins:vkr-arm-panicking, r=alexcr…
Rollup merge of rust-lang#65972 - braiins:vkr-arm-panicking, r=alexcr…
vojtechkral commentedon Nov 5, 2019
It would be cool if a fix for this (PR #65972) could be backport-nominated. Do you think it's eligible @pnkfelix @alexcrichton ?
alexcrichton commentedon Nov 5, 2019
Seems reasonable to me! Although we're in the middle of a release right now so it's going to end up on beta in a few days anyway and I don't think we'll rebuild the stable release to include that.
vojtechkral commentedon Nov 5, 2019
@alexcrichton Ok, thanks
stefson commentedon Nov 16, 2019
@vojtechkral do you still need some testing on other targets than arm-unknown-linux-musleabi? I can offer armv7a-unknown-linux-musleabihf (v1.38.0 and v1.39.0)
vojtechkral commentedon Nov 22, 2019
@stefson Sure, if you want, you can test which toolchains work (in terms of panicking) on that platform :)
stefson commentedon Nov 22, 2019
Ok, please give me instructions on what to exactly go for.
vojtechkral commentedon Nov 23, 2019
@stefson It should be enough to build & run a simple program that panics, such as:
If the toolchain's panicking support is broken, it may segfault or it may print an error message after the panic message is printed.