We experience CLR crash on some architectures (at least on x86) in case
of unhandled managed exception. libunwind steps to the very end of a
stack, and if .eh_frame info is correct, it returns with retcode 0 and
ip=0 from unw_step, then PAL calls unw_is_signal_frame with
c->validate==0 which in turn dereferences zeroed ip in access_mem.
libunwind spec says that retcode 0 from unw_step means very end of a
stack, so PAL should not expect any frames, signal or not. It should
convert cursor back to SEH representation and return with TRUE.
corresponding PR to dotnet/runtime on upstream:
https://github.com/dotnet/runtime/pull/42620
// Check if the frame we have unwound to is a frame that caused
// synchronous signal, like a hardware exception and record it
// in the context flags.
- if (unw_is_signal_frame(&cursor) > 0)
+ if ((st != 0) && (unw_is_signal_frame(&cursor) > 0))
{
context->ContextFlags |= CONTEXT_EXCEPTION_ACTIVE;
#if defined(_ARM_) || defined(_ARM64_) || defined(_X86_)