diff options
| author | Yaroslav Yamshchikov <y.yamshchiko@samsung.com> | 2020-09-18 15:25:21 +0300 |
|---|---|---|
| committer | 이형주/Common Platform Lab(SR)/Staff Engineer/삼성전자 <leee.lee@samsung.com> | 2020-10-05 09:53:20 +0900 |
| commit | 333691b8e3d7da54d9b90d5547a55d101db5edb3 (patch) | |
| tree | 10a332312507bbd6c8c1c1a7e210616d5436a483 | |
| parent | 3ac069e677a403f8345e092a43d51a7b103b1eb2 (diff) | |
| download | coreclr-333691b8e3d7da54d9b90d5547a55d101db5edb3.tar.gz coreclr-333691b8e3d7da54d9b90d5547a55d101db5edb3.tar.bz2 coreclr-333691b8e3d7da54d9b90d5547a55d101db5edb3.zip | |
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
| -rw-r--r-- | src/pal/src/exception/seh-unwind.cpp | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/pal/src/exception/seh-unwind.cpp b/src/pal/src/exception/seh-unwind.cpp index 3f40057d88..c5d0341b7e 100644 --- a/src/pal/src/exception/seh-unwind.cpp +++ b/src/pal/src/exception/seh-unwind.cpp @@ -314,7 +314,7 @@ BOOL PAL_VirtualUnwind(CONTEXT *context, KNONVOLATILE_CONTEXT_POINTERS *contextP // 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_) |