summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorYaroslav Yamshchikov <y.yamshchiko@samsung.com>2020-09-18 15:25:21 +0300
committerHyungju Lee <leee.lee@samsung.com>2020-10-07 08:02:12 +0900
commit1d0c47e37e0409271f304f401b439e8711c157e4 (patch)
treef385ada865c35cbcf1416b53427a95c5bc593def
parent07358a9c87521a70220d953c7fc0444a86807f62 (diff)
downloadcoreclr-submit/tizen_5.5_wearable_hotfix/20201030.060217.tar.gz
coreclr-submit/tizen_5.5_wearable_hotfix/20201030.060217.tar.bz2
coreclr-submit/tizen_5.5_wearable_hotfix/20201030.060217.zip
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.cpp2
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_)