Fix DAC hardware exception handling on Unix #79824
Conversation
Currently libmscordac doesn't install sigsegv handler and also isn't compiled with support for handling hardware exceptions in its native code. So when debugger ends up calling e.g. `MethodTable::ValidateWithPossibleAV` and the passed in `MethodTable` is invalid, e.g. located in an unmapped region of memory, the sigsegv causes the debugger to abort. It was found when using the ClrMD in BnechmarkDotNet disassembler code which is trying to find if some constants in the code represent `MethodTable` or `MethodDesc`. This change fixes it by setting the `PAL_INITIALIZE_REGISTER_SIGNALS` flag for `PAL_InitializeDLL` called from the mscordac's `DllMain` and adding the `FEATURE_ENABLE_HARDWARE_EXCEPTIONS` for the mscordac build.`
|
Tagging subscribers to this area: @tommcdon Issue DetailsCurrently libmscordac doesn't install sigsegv handler and also isn't compiled with support for handling hardware exceptions in its native code. So when debugger ends up calling e.g. This change fixes it by setting the
|
|
Interestingly, it was "broken" this way even in 3.1, 5.0 and 6.0. |
|
We purposely don't enable native exceptions in the DAC on Linux/MacOS because catching them and dispatching via a "software" exception through the C++ runtime doesn't always work. The C++ runtime doesn't expect exceptions at any arbitrary place in the code. The only way I've come up with to fix the ValidateWithPossibleAV functions is to make them fully DAC'ized so the invalid memory it accesses is done with read memory and a software exception is thrown/caught. I think I fixed some the places in 7.0 like in DacValidateMD, I know there are still more. This all works on Windows because SEH is used and the C++ can handle it. /cc: @jkotas |
|
Ah, now I remember, IIRC the issue was when the failure stems from functions where there is no try / catch in the method where the fault can occur (inlining can make it a bit better). I will close this PR and fix the issue by DAC-izing the methods that the BenchmarkDotNet disassembler uses. |
ghost
locked as resolved and limited conversation to collaborators
Currently libmscordac doesn't install sigsegv handler and also isn't compiled with support for handling hardware exceptions in its native code. So when debugger ends up calling e.g.
MethodTable::ValidateWithPossibleAVand the passed inMethodTableis invalid, e.g. located in an unmapped region of memory, the sigsegv causes the debugger to abort. It was found when using the ClrMD in BnechmarkDotNet disassembler code which is trying to find if some constants in the code representMethodTableorMethodDesc.This change fixes it by setting the
PAL_INITIALIZE_REGISTER_SIGNALSflag forPAL_InitializeDLLcalled from the mscordac'sDllMainand adding theFEATURE_ENABLE_HARDWARE_EXCEPTIONSfor the mscordac build.`