Skip to content

Panicking doesn't work on arm-unknown-linux-musleabi #65765

@vojtechkral

Description

@vojtechkral
Contributor

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:

  • 0x29a20 is inside _Unwind_RaiseException
  • 0x299cc is (the start of) _Unwind_RaiseException
  • 0x29f9c is __aeabi_unwind_cpp_pr0

Activity

added
C-bugCategory: This is a bug.
O-ArmTarget: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state
O-muslTarget: The musl libc
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
on Oct 24, 2019
vojtechkral

vojtechkral commented on Oct 27, 2019

@vojtechkral
ContributorAuthor

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

vojtechkral commented on Oct 30, 2019

@vojtechkral
ContributorAuthor

I think I probably know what the problem is. The method getByte() in file Unwind-EHABI.cpp in 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_Interpret get 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...

added a commit that references this issue on Oct 30, 2019
e9e4836
pnkfelix

pnkfelix commented on Oct 31, 2019

@pnkfelix
Contributor

triage: P-high. Has PR. assigning to @vojtechkral

vojtechkral

vojtechkral commented on Oct 31, 2019

@vojtechkral
ContributorAuthor

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

added 2 commits that reference this issue on Oct 31, 2019
9df994c
05de0d7
vojtechkral

vojtechkral commented on Nov 5, 2019

@vojtechkral
ContributorAuthor

It would be cool if a fix for this (PR #65972) could be backport-nominated. Do you think it's eligible @pnkfelix @alexcrichton ?

alexcrichton

alexcrichton commented on Nov 5, 2019

@alexcrichton
Member

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

vojtechkral commented on Nov 5, 2019

@vojtechkral
ContributorAuthor

@alexcrichton Ok, thanks

stefson

stefson commented on Nov 16, 2019

@stefson

@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

vojtechkral commented on Nov 22, 2019

@vojtechkral
ContributorAuthor

@stefson Sure, if you want, you can test which toolchains work (in terms of panicking) on that platform :)

stefson

stefson commented on Nov 22, 2019

@stefson

Ok, please give me instructions on what to exactly go for.

vojtechkral

vojtechkral commented on Nov 23, 2019

@vojtechkral
ContributorAuthor

@stefson It should be enough to build & run a simple program that panics, such as:

fn main() {
    panic!("Hello, World!");
}

If the toolchain's panicking support is broken, it may segfault or it may print an error message after the panic message is printed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

C-bugCategory: This is a bug.O-ArmTarget: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 stateO-muslTarget: The musl libcP-highHigh priorityT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    Participants

    @alexcrichton@pnkfelix@vojtechkral@jonas-schievink@stefson

    Issue actions

      Panicking doesn't work on arm-unknown-linux-musleabi · Issue #65765 · rust-lang/rust