This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Port to 3.1 - Fix handling thread abort in HelperMethodFrame (#28029)
The thread abort during func eval from a managed debugger on Linux and macOS was sometimes causing the debuggee to exit with unhandled c++ PAL_SEHException. The reason is that the thread abort detection that is done in the HELPER_METHOD_FRAME_BEGIN and ...END macros was done outside of the INSTALL_MANAGED_EXCEPTION_DISPATCHER / UNINSTALL_MANAGED_EXCEPTION_DISPATCHER region and so the exception thrown when thread abort request is detected there was not being caught and translated into a call to DispatchManagedException. Since the caller frame was a managed function frame, the C++ exception handling didn't know how to unwind it and so it declared the exception being unhandled. This fix moves the check for the thread abort out of the HelperMethodFrame::Push/Pop into a new method and calls that explicitly from the HELPER_METHOD_* macros inside the INSTALL_MANAGED_EXCEPTION_DISPATCHER / UNINSTALL_MANAGED_EXCEPTION_DISPATCHER region. That way, the thread abort exception is properly handled. # Customer impact .NET Core apps randomly terminate with unhandled c++ PAL_SEHException when a customer debugs an app under managed debuggers (VS Code, 3rd party debuggers) and tries to view a property value. # Regression? No, this problem has been present since .NET Core 1.0 # Testing CoreCLR pri 1 tests and .NET Core debugger tests. # Risk
- Loading branch information