SA stack dump fails to include stack trace for SteadyStateThread

SA sometimes can't get the stack trace for a thread. This is known to be an issue when the thread is active because sometimes ToS and "last java frame" cannot be determined. For this reason it is not considered a bug, but just a shortcoming since SA can't be expected to get a thread's stack trace no matter what state it is in.

A number of tests used to fail because of this. See JDK-8243455, which was fixed by introducing the SteadStateThread, a thread which blocks so jstack should always be able to get its stack trace. This fix has been in place since 2021-03-12, but we recently just saw for the first time a failure to get the stack of the SteadyStateThread. This is all jstack produces for the thread:

 "SteadyStateThread" #10 prio=5 tid=0x000001afc3e12af0 nid=0x85f4 waiting for monitor entry [0x000000922a6ff000]
   java.lang.Thread.State: BLOCKED (on object monitor)
   JavaThread state: _thread_blocked

It's unclear how this could happen. SA does need to do a fair amount of guessing and trial-and-error in its attempt to walk the stack. Possibly it thought it found a valid ToS, but that led to no frames, and because it thought it was valid it didn't continue searching for another valid ToS.

Note this is happening not only when using jstack, but also with dumpheap, which includes the stack trace in the heap dump.