diff options
author | Jan Vorlicek <janvorli@microsoft.com> | 2015-04-26 17:28:22 -0700 |
---|---|---|
committer | Jan Vorlicek <janvorli@microsoft.com> | 2015-04-26 17:42:00 -0700 |
commit | ec2354ec577b1fbe591018aa9fff6a769e3d2df4 (patch) | |
tree | 0a60dc3099e270e4d7a69565dce9fe25c8bc32d0 /crossgen.cmake | |
parent | d0714eefee86d8bafc5b5388bd4acf89f1f2d2ad (diff) | |
download | coreclr-ec2354ec577b1fbe591018aa9fff6a769e3d2df4.tar.gz coreclr-ec2354ec577b1fbe591018aa9fff6a769e3d2df4.tar.bz2 coreclr-ec2354ec577b1fbe591018aa9fff6a769e3d2df4.zip |
Fix GC of other thread during native frames unwinding
This change fixes a problem when the GC is attempting to scan a stack
of another thread that have just performed the native stack segment
unwind, but didn't have a chance to update the exception tracker
to reflect the fact that the stack range from m_pInitialExplicitFrame
and m_pLimitFrame is in the reclaimed part of the stack and is waiting
for the GC to complete (it uses the GCX_COOP).
The GC then attempts to scan explicit frames in the already reclaimed
part of the stack and crashes.
Besides fixing the issue, I have noticed that we are missing GCX_COOP
to enter the cooperative mode when unwinding frame chain in the
UnwindManagedExceptionPass1. I have also found that we don't have the
GCX_COOP in the HandleHardwareException properly scoped.
So I have fixed those as well.
Diffstat (limited to 'crossgen.cmake')
0 files changed, 0 insertions, 0 deletions