fix dwarf-based unwinding to the end of stack
authorYaroslav Yamshchikov <y.yamshchiko@samsung.com>
Fri, 18 Sep 2020 12:25:21 +0000 (15:25 +0300)
committer이형주/Common Platform Lab(SR)/Staff Engineer/삼성전자 <leee.lee@samsung.com>
Mon, 5 Oct 2020 00:53:20 +0000 (09:53 +0900)
commit333691b8e3d7da54d9b90d5547a55d101db5edb3
tree10a332312507bbd6c8c1c1a7e210616d5436a483
parent3ac069e677a403f8345e092a43d51a7b103b1eb2
fix dwarf-based unwinding to the end of stack

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
src/pal/src/exception/seh-unwind.cpp