On Thu, 16 Mar 2023 04:48:14 GMT, Prasanta Sadhukhan <[email protected]> wrote:
> > As per java/util/ConcurrentModificationException spec > > `this exception does not always indicate that an object has been > > concurrently modified by a different thread. If a single thread issues a > > sequence of method invocations that violates the contract of an object, the > > object may throw this exception. For example, if a thread modifies a > > collection directly while it is iterating over the collection with a > > fail-fast iterator, the iterator will throw this exception. ` > > so we should also see the sequence of operations on `fileCache` > > As per the exception log, we see > > ``` > at java.base/java.util.AbstractList.equals(AbstractList.java:544) > at > java.base/java.util.Collections$SynchronizedList.equals(Collections.java:2453) > at > java.desktop/javax.swing.plaf.basic.BasicDirectoryModel$FilesLoader$1.call(BasicDirectoryModel.java:358) > ``` > > where we have > > https://github.com/openjdk/jdk/blob/42dd9077a087e1431b76c5653db820e65a6cc177/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java#L352-L355 > > ie it is trying to get the element from same index twice > [`fileCache.get(i)`], not sure if it's an issue but can be optimised to get > it once (maybe a small testcase can be run in `Oracle linux` having 100's of > file objects and try to get the same element multiple times to see if it > returns ConcurrentModificationException) Could be, because mostly (with my test runs on linux and windows) the `filecache` will be empty, this condition executes when there are any elements in `filecache`. So whenever the `filecache` has some elements (which is intermittent according to the bug), this loop gets executed. Will do the test you recommended and see if that might be causing the problem. ------------- PR: https://git.openjdk.org/jdk/pull/13012
