JDK-8327137 : Add test for ConcurrentModificationException in BasicDirectoryModel
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 11,21
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-03-01
  • Updated: 2024-06-24
  • Resolved: 2024-04-10
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.
JDK 11 JDK 17 JDK 21 JDK 22 JDK 23 JDK 8
11.0.25-oracleFixed 17.0.13-oracleFixed 21.0.5-oracleFixed 22.0.2Fixed 23 b18Fixed 8u431Fixed
Related Reports
Relates :  
JDK-8332000 - BasicDirectoryModel/ConcurrentModification.java fails with Out of Memory
Relates :  
JDK-8307091 - A few client tests intermittently throw ConcurrentModificationException
Relates :  
JDK-8323670 - A few client tests intermittently throw ConcurrentModificationException
Relates :  
JDK-8240690 - Race condition between EDT and BasicDirectoryModel.FilesLoader.run0()
Description
I created a test to reproduce ConcurrentModificationException in BasicDirectoryModel. There were several attempts to fix the problem: JDK-8240690 and later JDK-8307091, JDK-8323670.

None of these fixes provided a reproducer.

During code review [1] for JDK-8323670, I mentioned that the problem can be reproduced by my test. After that, I fine-tuned the test. However, it doesn't always reproduce the problem, it's stable enough.

[1] https://github.com/openjdk/jdk/pull/17462#issuecomment-1914844026
Comments
Fix request [11u] I backport this for parity with 11.0.25-oracle. No risk, only tests change. Clean backport. Test pass. SAP nightly testing passed.
17-06-2024
Fix request [21u] I backport this for parity with 21.0.5-oracle. No risk, only a test change. Clean backport. Test pass. SAP nightly testing passed.
17-06-2024
Aprroval request for jdk21 is missing, should go in there first.
14-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2775 Date: 2024-06-14 08:52:30 +0000
14-06-2024
Fix request [17u] I backport this for parity with 17.0.13-oracle. No risk, only tests change. Clean backport. Test pass. SAP nightly testing passed.
12-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2713 Date: 2024-05-17 08:54:16 +0000
17-05-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2477 Date: 2024-05-17 08:51:22 +0000
17-05-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/584 Date: 2024-05-17 08:47:12 +0000
17-05-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk22u/pull/151 Date: 2024-04-17 11:50:15 +0000
17-04-2024
Fix request: 22u The changeset provides a regression test for JDK-8323670 (and, to a limited extent, for JDK-8325179.) The test fails without JDK-8323670. It is to be added after the backport for JDK-8323670 is integrated. Clean backport. Low risk. Pull request: https://github.com/openjdk/jdk22u/pull/151
17-04-2024
Changeset: 9731b1c8 Author: Alexey Ivanov <aivanov@openjdk.org> Date: 2024-04-10 14:21:37 +0000 URL: https://git.openjdk.org/jdk/commit/9731b1c8b02d957985f4fb40acd93fb67747a9f0
10-04-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18109 Date: 2024-03-04 15:52:45 +0000
04-03-2024
The test creates a number of files (NUMBER_OF_FILES) in a directory, then creates JFileChooser in this directory. Then the test starts several threads, controlled by NUMBER_OF_THREADS, which call fileChooser.rescanCurrentDirectory(). This results in calling BasicDirectoryModel.validateFileCache which starts a background thread to enumerate the files. Later, the background "Basic L&F File Loading Thread" posts an event to EDT. It is in the event handled on EDT that `fileCache` is modified… while the background "File Loading Thread" reads the values from `fileCache` and iterate over it. The timing must match for the error to occur, the contents of `fileCache` should be modified while "File Loading Thread" is iterating over `fileCache`. For this reason, the test does not fail reliably, you need to run it several times. On macOS, the test needs to be run in headless mode with -Djava.awt.headless=true; on Linux, it's not necessary, however, I still recommend passing headless=true.
04-03-2024