On Tue, 4 Aug 2026 21:11:39 GMT, Chris Plummer <[email protected]> wrote:
>> Shiv Shah has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Resolve tested threads by exact name to avoid ordering assumption > >> suspend/suspend001 - after "suspend " of the virtual thread plus "cont", >> jdb stops responding (no prompt); happy to file a separate bug if this looks >> like a jdb/JDI issue worth tracking > > Yes, I think this is worth filing and looking into. Try to include mach5 > results so I can look into it more easily. @plummercj reworked as discussed: all 10 -trackallthreads additions have been removed. For tests whose virtual threads were not otherwise known to jdb, each tested thread now passes through a threadStarted() rendezvous breakpoint before the lookup. Once jdb receives that event, the thread remains discoverable and switchable using the default agent behavior. exclude001, pop001 and reenter001 already receive suitable events at lastBreak(), so they needed only the option removed. The rendezvous loops match the fully qualified breakpoint method name as one token because debuggee output can interleave with jdb's "Breakpoint hit:" output. Validation encountered one such splice, which is why the matching is deliberately specific @sspitsyn your exact-name lookup is unchanged and the rework relies on it and the threads reach the rendezvous out of creation order ------------- PR Comment: https://git.openjdk.org/jdk/pull/32142#issuecomment-5196616306
