You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 23, 2023. It is now read-only.
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
0 commit comments