Secondary frame stackoverflow test failure on linux

[am11]

This test:

runtime/src/tests/baseservices/exceptions/stackoverflow/stackoverflowtester.cs

Line 157 in ac663e4

public static void TestStackOverflowSmallFrameSecondaryThread()

is failing in runtime-coreclr superpmi-collect-test pipeline on linux x64, arm64 and arm:

Running stackoverflow test(largeframe main)
"Stack overflow."
"Repeated 42 times:"
"--------------------------------"
"   at TestStackOverflow.Program.InfiniteRecursionB2()"
"   at TestStackOverflow.Program.InfiniteRecursionA2()"
"   at TestStackOverflow.Program.InfiniteRecursionC2()"
"--------------------------------"
"   at TestStackOverflow.Program.InfiniteRecursionB2()"
"   at TestStackOverflow.Program.InfiniteRecursionA2()"
"   at TestStackOverflow.Program.Test(Boolean)"
"   at TestStackOverflow.Program.Main(System.String[])"
""
Running stackoverflow test(smallframe secondary)
"Stack overflow."
"Stack overflow."
""
System.Exception: Missing "TestStackOverflow.Program.Test" method frame
   at TestStackOverflow.Program.TestStackOverflowSmallFrameSecondaryThread()
   at __GeneratedMainWrapper.Main()
Expected: 100
Actual: 101
END EXECUTION - FAILED

cc @janvorli

[janvorli]

The problem is due to the superpmi libsuperpmi-shim-collector.so sigsegv handler being called as the first one and the GetCurrentPalThread returning NULL in this dll, because the PAL threads were created by the libcoreclr.so. That results in the sigsegv_handler printing "Stack overflow" and calling PROCAbort.
I am testing a fix that just calls the previous signal handler when GetCurrentPalThread returns NULL.

[janvorli]

It is actually a bit more involved. The GetCurrentPalThread sometimes returns non-NULL even when called from the libsuperpmi-shim-collector.so SIGSEGV handler. That happens when the superpmi stuff ended up being called on that thread before the crash occurs. Which means we have jitted something on that thread. Then the PAL thread instance gets created also in the context of the libsuperpmi-shim-collector.so.
Nevertheless, it doesn't change the way to fix that I've mentioned above. I just wanted to share the full story here. If the PAL thread got registered, we still end up falling back to the SIGSEGV handler in the libcoreclr.so, because the superpmi doesn't implement hardware exception handling callbacks that could handle the stack overflow.