JDK-8345501 : Test TestEvilSyncBug.java#generational intermittent timed out
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 24
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • CPU: x86_64
  • Submitted: 2024-12-04
  • Updated: 2025-04-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8345970 - pthread_getcpuclockid related crashes in shenandoah tests
Sub Tasks
JDK-8347279 :  
Problemlist TestEvilSyncBug.java#generational - Resolved
Description
Test gc/shenandoah/TestEvilSyncBug.java#generational intermittent timed out on linux-x64, the test log snippet:

"pool-1-thread-1" #39 [478519] prio=5 os_prio=0 cpu=16.52ms elapsed=1919.89s tid=0x00007f56a0006dc0 nid=478519 waiting on condition  [0x00007f5755a6f000]
   java.lang.Thread.State: WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base@24-internal/Native Method)
    - parking to wait for  <0x00000001191904f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(java.base@24-internal/LockSupport.java:369)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base@24-internal/AbstractQueuedSynchronizer.java:519)
    at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base@24-internal/ForkJoinPool.java:3946)
    at java.util.concurrent.ForkJoinPool.managedBlock(java.base@24-internal/ForkJoinPool.java:3892)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@24-internal/AbstractQueuedSynchronizer.java:1751)
    at java.util.concurrent.LinkedBlockingQueue.take(java.base@24-internal/LinkedBlockingQueue.java:435)
    at java.util.concurrent.ThreadPoolExecutor.getTask(java.base@24-internal/ThreadPoolExecutor.java:1021)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@24-internal/ThreadPoolExecutor.java:1081)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@24-internal/ThreadPoolExecutor.java:619)
    at java.lang.Thread.runWith(java.base@24-internal/Thread.java:1460)
    at java.lang.Thread.run(java.base@24-internal/Thread.java:1447)

"Thread-62" #175 [492747] daemon prio=5 os_prio=0 cpu=0.18ms elapsed=1918.64s tid=0x00007f5684006950 nid=492747 runnable  [0x00007f57478f7000]
   java.lang.Thread.State: RUNNABLE
    at java.io.FileInputStream.readBytes(java.base@24-internal/Native Method)
    at java.io.FileInputStream.read(java.base@24-internal/FileInputStream.java:294)
    at java.lang.Process$PipeInputStream.read(java.base@24-internal/Process.java:897)
    at java.io.BufferedInputStream.read1(java.base@24-internal/BufferedInputStream.java:328)
    at java.io.BufferedInputStream.read(java.base@24-internal/BufferedInputStream.java:388)
    - locked <0x000000011fbbf520> (a java.lang.ProcessImpl$ProcessPipeInputStream)
    at java.io.BufferedInputStream.fill(java.base@24-internal/BufferedInputStream.java:289)
    at java.io.BufferedInputStream.read1(java.base@24-internal/BufferedInputStream.java:330)
    at java.io.BufferedInputStream.read(java.base@24-internal/BufferedInputStream.java:388)
    - locked <0x000000011b865b50> (a java.io.BufferedInputStream)
    at java.io.FilterInputStream.read(java.base@24-internal/FilterInputStream.java:95)
    at jdk.test.lib.process.StreamPumper.run(StreamPumper.java:111)
    at java.util.concurrent.Executors$RunnableAdapter.call(java.base@24-internal/Executors.java:545)
    at java.util.concurrent.FutureTask.run(java.base@24-internal/FutureTask.java:328)
    at java.lang.Thread.runWith(java.base@24-internal/Thread.java:1460)
    at java.lang.Thread.run(java.base@24-internal/Thread.java:1447)
Comments
Maybe duolicated to JDK-8351231. Need to check this failure can be reproduce or not.
02-04-2025
> We would need to set TEST_THREAD_FACTORY=Virtual explicitly in the jtreg call, correct ? Yes. The documentation is https://github.com/openjdk/jdk/blob/master/doc/testing.md?plain=1#L383
08-01-2025
> Does the timed out fails run with TEST_THREAD_FACTORY=Virtual or run without TEST_THREAD_FACTORY=Virtual From what I know and got from our test responsible, it is without TEST_THREAD_FACTORY=Virtual. We would need to set TEST_THREAD_FACTORY=Virtual explicitly in the jtreg call, correct ?
08-01-2025
[~mbaesken] Hi, "We saw so far 6 timeouts in January" Does the timed out fails run with TEST_THREAD_FACTORY=Virtual or run without TEST_THREAD_FACTORY=Virtual
08-01-2025
gc/shenandoah/TestEvilSyncBug.java#generational times out on a lot of platforms (various Linux and Windows too). We saw so far 6 timeouts in January. Should we mark this test intermittent? Or put it into the problem list for now ?
08-01-2025
There are some other shenandoah#generational tests timed out which recorded by JDK-8345958. Maybe this timed out failure unrelated to virtual thread.
14-12-2024
The usage of 'TEST_THREAD_FACTORY=Virtual' recorded by https://github.com/openjdk/jdk/blob/master/doc/testing.md?plain=1#L383
14-12-2024
I saw this test timeout even after the fix for https://bugs.openjdk.org/browse/JDK-8345970. The `TEST_THREAD_FACTORY=Virtual` is new to me. Have you seen other test failures with this configuration? or only this test? Also, I do not see the configuration applied by `TEST_THREAD_FACTORY=Virtual` in the `rerun` section of the jtreg log, so I'm not quite sure how to reproduce this is in a debugger outside of jtreg.
13-12-2024
Failure probability about 27/10k
05-12-2024