Closed Maoni0 closed 4 years ago
I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.
@Maoni0 I have a presumptive fix here: https://github.com/dotnet/runtime/pull/36151. Though from what I can see the watson codepath should only be hit in unhandled exception scenarios?
chatted with some folks who are more familiar with EH about this. the gist is there may be code paths that handle exceptions that the runtime may not know for sure are unhandled (so they may or may not be unhandled later), at least this was the case on desktop. also this does hit a particular EH which is ReflectionInvocationExceptionFilter. the process clearly kept on running for the case I looked at.
Ok I was able to hit the watson codepath with the reflection invocation exception case. Looks like ReflectionInvocationExceptionFilter
switches to COOP just before calling SetupWatsonBucketsForNonPreallocatedExceptions
: https://github.com/dotnet/runtime/blob/e77572ffccc566186f47207f3c5475533c87538e/src/coreclr/src/vm/excep.cpp#L8441
Assume that is required to gcprotect oThrowable
?
fix has been merged
I'm observing this code from EH is preventing suspension from completing in a timely manner -
CallDescrWorkerReflectionWrapper'::
1'::filt$0or DwGetFileVersionInfo could do that before calling GetFileVersion. this is causing suspension that's 3 to 4s long.