On Fri, 28 Jun 2024 20:34:48 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
> The completely unrelated fix to > [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) led me to believe > that the issue with sometimes not being able to get the stack trace of the > SteadyStateThread might be due to the thread being active for a short period > after being reported as in the Thread.State.BLOCKED state. Once set to that > state, the thread still needs to call a native OS API to block the thread so > it is truly idle. During this time the thread stack might be inconsistent and > not walk-able. The fix is to add a short sleep after the thread has moved to > the Thread.State.BLOCKED state to give it a chance to finish blocking. > > Tested with Tier1 CI and all svc test tasks for tier2 and tier5. This is the most simple solution but not 100% reliable. Looks okay to me. test/lib/jdk/test/lib/apps/LingeredApp.java line 589: > 587: } > 588: > 589: // Wait a short period of time so we can be sure the thread > truly is blocked. See JDK-8269881. Nit: Would this be better?: "truly is blocked" => "is truly blocked" ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19951#pullrequestreview-2155294863 PR Review Comment: https://git.openjdk.org/jdk/pull/19951#discussion_r1663448562
