fix dwarf-based unwinding to the end of stack (#42620)
authorYaroslav Yamshchikov <y.yamshchiko@samsung.com>
Wed, 23 Sep 2020 19:26:18 +0000 (22:26 +0300)
committerGitHub <noreply@github.com>
Wed, 23 Sep 2020 19:26:18 +0000 (21:26 +0200)
commitfbe5383cb3f53a3b1137e0a33ddefe0e27a921ff
treed46145f991061b2a884b0de3a759ca58d829352a
parent6f7d32d1c73e6d9188be82361ebb4307a6e26ea7
fix dwarf-based unwinding to the end of stack (#42620)

We experience CLR crash on some architectures (at least in 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.
src/coreclr/src/pal/src/exception/seh-unwind.cpp