SEGV in unix::stack_overflow::signal_handler

[aep]

with --target arm-unknown-linux-musleabi i get a SEGV in env_logger::Format::into_boxed_fn::_$u7b$$u7b$closure$u7d$$u7d$::ha67fa042fe85d5e5 which contains no unsafe code

rust-cli/env_logger#106

but i suspect its actually crashing in unix::stack_overflow::signal_handler according to this qemu cpu trace

https://gist.github.com/4b83c01143f582e95c77a526710f18e3

this only happens with musl, not with glibc, so might be TLS related?

[sfackler]

The signal handler doesn't log, so I think the env_logger symbol may be a red herring.

[aep]

This is happening when log is called from somewhere else. Maybe env_logger::Format::into_boxed_fn is actually crashing, which triggers the signal handler? I don't quite understand what the handler actually does.

btw also only happens in --release mode. debug is fine.

• release
• arm
• musleabi

any more debug info i can obtain to help figure this out?

[sfackler]

Oh, I read that trace as a stacktrace, not as a sequence of instructions. The stack overflow handler handles all SEGVs - if the signal was not due to a stack overflow it deregisters itself and the signal is re-emitted and handled as usual. That's what happened in this case, so it's not a stack overflow, just a "normal" SEGV.

[aep]

yeah looks like it. i'm confused why musl is even related to this. Is it possible that there's an incorrectly emitted reloc?

[sfackler]

There are some MUSL-specific issues with unwind info, but I don't know if that's related here: #47551.

[steveklabnik]

Triage: are you, or is anyone else, still seeing this problem? Any chance of getting a smaller reproduction?

[aep]

We're no longer using rust. But it's unlikely to be fixed since rust still ships the wrong musl crt and uses TLS excessively.

[steveklabnik]

Okay! I'm going to close this then; we'll see if anyone else runs into it. Thanks!