JDK-8333880 : BasicDirectoryModel/LoaderThreadCount.java still fails frequently on Windows in CI
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 23,24
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows
  • Submitted: 2024-06-10
  • Updated: 2025-01-03
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-8331999 - BasicDirectoryModel/LoaderThreadCount.java frequently fails on Windows in CI
Sub Tasks
JDK-8337810 :  
ProblemList BasicDirectoryModel/LoaderThreadCount.java on Windows - Resolved
Description
Even after JDK-8331999 we still see the javax/swing/plaf/basic/BasicDirectoryModel/LoaderThreadCount.java test fails more than 50% of the time in our CI tests. Currently we see these failures only on Windows and only in head.

A typical output would be:

Number of snapshots: 20
Number of snapshots where number of loader threads:
  = 1: 4
  = 2: 4
  > 2: 12
Duration: 17,467

The highest failure value I have seen was 13, but I only looked at 10 of our failed runs of the last weeks. Our tests run headless and with concurrency equal to the number of CPUs.
Comments
we get also quite a lot of failures of javax/swing/plaf/basic/BasicDirectoryModel/LoaderThreadCount.java on Windows in our test infrastructure , e.g. : Exception in Test Runner: class java.lang.RuntimeException: Detected 16 snapshots with several loading threads java.lang.RuntimeException: Detected 16 snapshots with several loading threads at LoaderThreadCount.runTest(LoaderThreadCount.java:168) at LoaderThreadCount.wrapper(LoaderThreadCount.java:108) at java.base/java.lang.Thread.run(Thread.java:1575) Can we mark it intermittent , or exclude it for now ?
02-08-2024
Copying over the relevant comments from JDK-8331999: What I can think of is that I also need to verify the interrupted status of the thread. If the background thread is already interrupted but is still running, it's not a failure condition… exiting from an interrupted thread could take quite a while, especially on a system under heavy load. Unless something odd is happening, such that the fix for JDK-8325179 isn't working. I've been thinking about using a custom FileSystemView, it may simplify the test and make it more stable. Now the test relies on enumerating live threads, a custom FileSystemView could track the threads directly: on which thread its listFiles method is called.
10-06-2024
This bug is originally reported as a comment: https://bugs.openjdk.org/browse/JDK-8331999?focusedId=14679116&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14679116
10-06-2024