Fix stack overflow reporting with multiple PALs #107264
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 |
3 tasks
|
/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. 👍 |
jkotas
reviewed
Sep 4, 2024
|
cc @lambdageek Aleksey has been looking into removing superpmi dependency on PAL exception handling. |
jkotas
approved these changes
Sep 4, 2024
👍 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 |
3 tasks
jtschuster
pushed a commit
to jtschuster/runtime
that referenced
this pull request
Sep 17, 2024
* 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
sirntar
pushed a commit
to sirntar/runtime
that referenced
this pull request
Sep 30, 2024
* 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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