Fix stack overflow reporting with multiple PALs #107264
Conversation
A recently reported issue in the stack overflow test running with superpmi collect has revealed that there is a problem when multiple shared libraries using coreclr PAL are loaded into the process. Each such library registers signal handlers, including the SIGSEGV one. The unexpected thing in the SIGSEGV handler in this scenario is the fact that the GetCurrentPalThread() returns NULL in the non-coreclr shared libraries in case the library didn't invoke any function that would create the thread object. That leads to the handler just writing "Stack overflow." to the console and then calling PROCAbort(). This abort causes the process to be torn down without reporting the stack overflow with full stack trace by the coreclr. This change fixes it by calling the previous registered handler instead aborting in this case. That gives the coreclr SIGSEGV handler a chance to do the reporting as expected.
|
Thank you! Please execute |
|
/azp run runtime-coreclr superpmi-collect-test |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
#107277 should fix superpmi-collect-test. |
|
All runtime tests passed though, so seems like this change fixes the problem. |
|
Yes, it was failing on x64 as well, which is now green. 👍 |
|
cc @lambdageek Aleksey has been looking into removing superpmi dependency on PAL exception handling. |
👍 My idea is to remove the Like the changes here, by SIGSEGV handler will chain to the previous one, if it is present, rather than abort |
* Fix stack overflow reporting with multiple PALs A recently reported issue in the stack overflow test running with superpmi collect has revealed that there is a problem when multiple shared libraries using coreclr PAL are loaded into the process. Each such library registers signal handlers, including the SIGSEGV one. The unexpected thing in the SIGSEGV handler in this scenario is the fact that the GetCurrentPalThread() returns NULL in the non-coreclr shared libraries in case the library didn't invoke any function that would create the thread object. That leads to the handler just writing "Stack overflow." to the console and then calling PROCAbort(). This abort causes the process to be torn down without reporting the stack overflow with full stack trace by the coreclr. This change fixes it by calling the previous registered handler instead aborting in this case. That gives the coreclr SIGSEGV handler a chance to do the reporting as expected. * Reflect PR feedback - move comment
A recently reported issue in the stack overflow test running with superpmi collect has revealed that there is a problem when multiple shared libraries using coreclr PAL are loaded into the process. Each such library registers signal handlers, including the SIGSEGV one. The unexpected thing in the SIGSEGV handler in this scenario is the fact that the GetCurrentPalThread() returns NULL in the non-coreclr shared libraries in case the library didn't invoke any function that would create the thread object.
That leads to the handler just writing "Stack overflow." to the console and then calling PROCAbort(). This abort causes the process to be torn down without reporting the stack overflow with full stack trace by the coreclr.
This change fixes it by calling the previous registered handler instead aborting in this case. That gives the coreclr SIGSEGV handler a chance to do the reporting as expected.
Close #107226