On Tue, 28 Oct 2025 01:38:49 GMT, Yasumasa Suenaga <[email protected]> wrote:
>> `jhsdb jstack --mixed` would not work when attaches to the process runs with >> `-Xcomp`. >> >> It has been reported by @pchilano in #27728. You can reproduce the problem >> with [Test.java (attached >> JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can >> see following stack. >> >> >> ----------------- 646689 ----------------- >> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition >> [0x00007f1cd0158000] >> java.lang.Thread.State: TIMED_WAITING (sleeping) >> JavaThread state: _thread_blocked >> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32 >> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c >> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178 >> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119 >> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc >> 0x00007f1cf218789f JVM_SleepNanos + 0x28f >> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method) >> >> >> `Thread.sleepNanos0` is the bottom stack, but actually it has more call >> frames. You can see them with `-XX:+PreserveFramePointer`. >> >> >> ----------------- 646841 ----------------- >> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition >> [0x00007f49e4fd7000] >> java.lang.Thread.State: TIMED_WAITING (sleeping) >> JavaThread state: _thread_blocked >> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32 >> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c >> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178 >> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119 >> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc >> 0x00007f4a0918789f JVM_SleepNanos + 0x28f >> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method) >> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 >> (Compiled frame) >> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled >> frame) >> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame) >> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, >> java.lang.Runnable) bci:5 line:1487 (Compiled frame) >> * java.lang.Thread.run() bci:19 line:1474 (Compiled >> frame) >> 0x00007f49ef3385fd <StubRoutines (initial stubs)> >> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, >> JavaCallArguments*, JavaThread*) + 0x4ce >> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, >> Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3 >> 0x00007f4a08fc31bb JavaCalls::call_virtu... > > Yasumasa Suenaga has updated the pull request incrementally with one > additional commit since the last revision: > > TestJhsdbJstackMixedWithXComp.java should be run on Linux AMD64 only test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithXComp.java line 63: > 61: System.err.println(out.getStderr()); > 62: > 63: out.stderrShouldBeEmptyIgnoreDeprecatedWarnings(); I might want you to change this to stderrShouldBeEmptyIgnoreVMWarnings(). We have issues with our internal testing when using -XX:+UseLargePages that sometimes results in a VM warning on stderr that causes this (and some other tests) to fail. We are still deciding on the best approach to fixing this, but I think the solution is most likely to be switching to stderrShouldBeEmptyIgnoreDeprecatedWarnings(). Hopefully I'll know within the next day. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2471522955
