RFR: 8313235: TestClhsdbJstackLock.java failed with '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class for LingeredAppWithLock\)$' missing from stdout/stderr

[Leonid Mesnik]

On Fri, 28 Jun 2024 22:30:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Once the main thread has detected that the spawned thread is in the BLOCKED state, the spawned thread's LingeredAppWithLock.lockMethod() should be visible on the top of the stack, but it is not, so the "waiting to lock" message is missing from the stack trace.
> 
> I think the explanations mentioned in [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) and [JDK-8269881](https://bugs.openjdk.org/browse/JDK-8269881) apply here also. The state of the thread has moved to BLOCKED, but the thread still needs to finish making an OS call to actually become blocked and the thread become idle. During that time we may not be able to get an accurate stack trace. In this case probably SP has not been flushed, so we are not seeing the lockMethod() frame, which should appear at the top of the stack.
> 
> A short delay has been added after all threads have entered the desired state to make sure they have fully reached the desired state and are now idle.
> 
> Tested with Tier1 CI and all svc test tasks for tier2 and tier5.

Although I don't like using Thread.sleep(), seems there  are no any other way to fir the problem.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19953#pullrequestreview-2184368963