fix dwarf-based unwinding to the end of stacksubmit/tizen_5.5_wearable_hotfix/20201030.060217accepted/tizen/5.5/unified/wearable/hotfix/20201103.003343tizen_5.5accepted/tizen_5.5_unified_wearable_hotfix

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

0 files changed, 0 insertions, 0 deletions