Bug 178439 - [69cat] ConcurrentModificationException in NbPreferences
[69cat] ConcurrentModificationException in NbPreferences
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Options&Settings
6.x
All All
: P1 (vote)
: 6.x
Assigned To: Jiri Rechtacek
issues@platform
http://statistics.netbeans.org/analyt...
68patch-candidate
: RANDOM, THREAD
: 179372 181409 182994 183338 183392 183525 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-10 11:30 UTC by jamespb
Modified: 2010-04-07 04:43 UTC (History)
13 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
messages.log (38.82 KB, application/octet-stream)
2009-12-10 11:30 UTC, jamespb
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jamespb 2009-12-10 11:30:41 UTC
Created attachment 92391 [details]
messages.log

Starting up this morning's version of Netbeans to work on a Ruby project, I get the following exception (also including messages.log)

java.util.ConcurrentModificationException
	at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761)
	at java.util.LinkedList$ListItr.add(LinkedList.java:752)
	at org.openide.util.EditableProperties.addItem(EditableProperties.java:393)
	at org.openide.util.EditableProperties.put(EditableProperties.java:250)
	at org.netbeans.core.startup.preferences.NbPreferences.putSpi(NbPreferences.java:123)
	at java.util.prefs.AbstractPreferences.put(AbstractPreferences.java:234)
	at org.netbeans.core.startup.preferences.NbPreferences.put(NbPreferences.java:133)
	at org.netbeans.modules.autoupdate.updateprovider.AutoupdateCatalogFactory.createUpdateProvider(AutoupdateCatalogFactory.java:125)
Caused: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.netbeans.core.startup.layers.BinaryFS$AttrImpl$MethodAndParams.invoke(BinaryFS.java:604)
	at org.netbeans.core.startup.layers.BinaryFS$AttrImpl.getValue(BinaryFS.java:537)
	at org.netbeans.core.startup.layers.BinaryFS$BFSBase.getAttribute(BinaryFS.java:383)
	at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:844)
	at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:793)
	at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:840)
	at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:793)
	at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:726)
	at org.openide.loaders.InstanceDataObject$Ser.instanceCreate(InstanceDataObject.java:1370)
	at org.openide.loaders.InstanceDataObject.instanceCreate(InstanceDataObject.java:818)
	at org.openide.loaders.FolderLookup$ICItem.getInstance(FolderLookup.java:584)
	at org.openide.util.lookup.AbstractLookup$R.allInstances(AbstractLookup.java:1003)
	at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:548)
	at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:488)
	at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:548)
	at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:488)
	at org.netbeans.modules.autoupdate.services.UpdateUnitProviderImpl$LookupListenerImpl.allInstances(UpdateUnitProviderImpl.java:451)
	at org.netbeans.modules.autoupdate.services.UpdateUnitProviderImpl.getUpdateUnitProviders(UpdateUnitProviderImpl.java:254)
	at org.netbeans.modules.autoupdate.services.UpdateUnitProviderImpl.refreshProviders(UpdateUnitProviderImpl.java:300)
	at org.netbeans.modules.autoupdate.services.UpdateUnitProviderImpl$LookupListenerImpl.resultChanged(UpdateUnitProviderImpl.java:444)
	at org.openide.util.lookup.AbstractLookup$NotifyListeners.run(AbstractLookup.java:525)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:641)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1123)
Comment 1 dlipin 2009-12-11 08:06:25 UTC
Seems to be autoupdate issue, reassigning. Not that critical since it occurs rarely.
Comment 2 dlipin 2010-01-11 05:00:03 UTC
*** Bug 179372 has been marked as a duplicate of this bug. ***
Comment 3 Vladimir Voskresensky 2010-01-11 14:06:31 UTC
already 40 duplicates
Comment 4 dlipin 2010-02-08 05:03:50 UTC
Jarda,

Could you please advise on what is wrong with the current usage of Lookup/NbPreferences?
Or is it an issue in Lookup/filesystems that causes such an issue?
Thanks.
Comment 5 Jaroslav Tulach 2010-02-08 09:49:01 UTC
As far as I know Preferences implementation shall be thread safe. Obviously it is not.
Comment 6 dlipin 2010-03-02 06:30:15 UTC
*** Bug 181409 has been marked as a duplicate of this bug. ***
Comment 7 Jesse Glick 2010-03-02 07:09:35 UTC
I think I've hit this on occasion too.
Comment 8 Jaroslav Tulach 2010-04-01 14:26:41 UTC
381 duplicates.
Comment 9 Jesse Glick 2010-04-02 17:00:26 UTC
*** Bug 183338 has been marked as a duplicate of this bug. ***
Comment 10 Jesse Glick 2010-04-02 17:00:53 UTC
*** Bug 183392 has been marked as a duplicate of this bug. ***
Comment 11 Jesse Glick 2010-04-02 17:04:25 UTC
*** Bug 182994 has been marked as a duplicate of this bug. ***
Comment 12 Jesse Glick 2010-04-02 17:08:13 UTC
Various other symptoms may be observed. Simply need to synchronize all accesses to EditableProperties, as (like HashMap) it is not intended to be thread-safe.
Comment 13 Jiri Rechtacek 2010-04-06 09:16:28 UTC
*** Bug 183525 has been marked as a duplicate of this bug. ***
Comment 14 Marian Mirilovic 2010-04-06 10:18:50 UTC
630 duplicates ... P1 (sorry Jirka, but this needs to be addressed for NB 6.9)
Comment 15 Jiri Rechtacek 2010-04-06 14:10:56 UTC
fixed in core-main/rev/57212e84a471
Comment 16 Jesse Glick 2010-04-06 14:55:54 UTC
(In reply to comment #15)
> core-main #57212e84a471

flushSpi does not synchronize. Anyway shouldn't you be using AbstractPreferences.lock rather than inventing a new lock?
Comment 17 Jiri Rechtacek 2010-04-06 15:07:15 UTC
> --- Comment #16 from Jesse Glick <jglick@netbeans.org>  2010-04-06 14:55:54 ---
> flushSpi does not synchronize. Anyway shouldn't you be using
flushSpi doesn't write into EditableProperties map thus I omit it.
> AbstractPreferences.lock rather than inventing a new lock?
Well, makes sense. I'll change it to use that lock. Thanks
Comment 18 Jiri Rechtacek 2010-04-06 15:11:56 UTC
> --- Comment #17 from Jiri Rechtacek <jrechtacek@netbeans.org>  2010-04-06 15:07:15 ---
>> --- Comment #16 from Jesse Glick <jglick@netbeans.org>  2010-04-06 14:55:54 ---
>> flushSpi does not synchronize. Anyway shouldn't you be using
> flushSpi doesn't write into EditableProperties map thus I omit it.
My wrong, flushSpi writes in map as well. I'll fix it.
Comment 19 Jesse Glick 2010-04-06 15:14:04 UTC
(In reply to comment #17)
> flushSpi doesn't write into EditableProperties map thus I omit it.

But it _reads_ properties, meaning that a concurrent write to properties could result in a CME on one or the other thread.
Comment 20 Jiri Rechtacek 2010-04-06 18:00:26 UTC
Jesse's hints impl. in core-main/rev/5dac466bc973 Thanks
Comment 21 Quality Engineering 2010-04-07 04:43:32 UTC
Integrated into 'main-golden', will be available in build *201004070201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/57212e84a471
User: Jiri Rechtacek <jrechtacek@netbeans.org>
Log: #178439: ConcurrentModificationException in NbPreferences


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo