Fix null reference exception handling in JIT_WriteBarrier
authorJan Vorlicek <janvorli@microsoft.com>
Thu, 10 Sep 2015 22:56:25 +0000 (00:56 +0200)
committerJan Vorlicek <janvorli@microsoft.com>
Thu, 10 Sep 2015 22:56:25 +0000 (00:56 +0200)
commitaf76ec004c3d7c50abe29ddbfd3be37df30e21cb
tree10299677581d7c4207acf94535be0f3a2a7e3001
parentb4c53d212ab86bdc1b9b948b22f88a0aea894fab
Fix null reference exception handling in JIT_WriteBarrier

This change fixes an issue when a null reference exception happens in the first
instruction of the JIT_WriteBarrier. There were two problems.

First problem was that the native unwinder didn't know that it is unwinding a
frame where the PC is an address of a failing instruction instead of the next
address after a call instruction. So it decremented the PC before looking up the
unwind info. Unfortunately, that means that if the hardware exception happens
in the first instruction, the unwind info is not found and the unwinder resorts
to RBP chain unwinding, which effectively skips one managed frame.

The second problem was that the FaultingExceptionFrame we create when handling
the hardware exception had context pointing to the JIT_WriteBarrier. But that
breaks the stack walker. When it arrives at the FaultingExceptionFrame, it
calls its ReturnAddress method and expects to get a managed code address.
However, in this case, it was getting the address of the JIT_WriteBarrier instead
and that made the stack walker to skip to the next explicit frame, effectively
skipping multiple managed frames that it should have reported.
src/pal/src/exception/seh-unwind.cpp
src/vm/exceptionhandling.cpp