This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Netbeans hangs on edit of project properties, showing the "Saving project data" dialog. This seems to happen on a second attempt to edit project properties. Have to kill the process and restart. I know this issue was previously reported as #141326, which is marked as fixed and resolved.
Created attachment 77149 [details] output from jstack -l
this is another issue that #141326. It seems web project is causing this.
Looking at thread dump it does not look like a deadlock. All threads are waiting for a write lock on project and the thread which is holding the lock is executing a code in thread dump (org.openide.util.ChangeSupport.addChangeListener(ChangeSupport.java:83)) so perhaps it was in a loop or took too much time but it does not look as deadlock. Does it ever happened again? Couple of thread dumps might help identify if code is still progressing.
I've run it this morning and so far it's taken more than 30 minutes on "Saving project data". The java process is taking about 50% CPU the whole time (dual core machine). I am attaching some jstack outputs from that period.
Created attachment 78364 [details] jstack output (oops, first few without -l).
Thanks Adrien, appreciated! I cannot explain this deadlock! It does not make sense to me. Following thread is causing deadlock and in all thread dumps the thread is in the same state yet I do not know why it's not moving. There is IMO no reason why underlying CopyOnWriteArrayList used by ChangeSupport class should be locked and prevent it from moving: "Default RequestProcessor" daemon prio=2 ...] java.lang.Thread.State: RUNNABLE at org.openide.util.ChangeSupport.addChangeListener(ChangeSupport.java:83) at org.netbeans.spi.project.support.LookupProviderSupport$SourcesImpl.addChangeListener(LookupProviderSupport.java:269) at org.netbeans.modules.j2ee.ddloaders.app.EarDataObject.refreshSourceFolders(EarDataObject.java:149) at org.netbeans.modules.j2ee.ddloaders.app.EarDataObject.stateChanged(EarDataObject.java:738) at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:123) at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:109) at org.netbeans.spi.project.support.LookupProviderSupport$SourcesImpl.stateChanged(LookupProviderSupport.java:277) at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:123) at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:109) at org.netbeans.modules.web.project.WebSources.fireChange(WebSources.java:180) EarDataObject.refreshSourceFolders() seems to be a little bit dumb and keep adding listener to project sources anytime there is a state change regardless of whether it is already listening on the source or not. That something what should be fixed but that should not cause this deadlock, right? Passing to core experts for opinion.
This is not typical deadlock. One thread seems running forever and all other threads are waiting for it to get access. Problem is with this not finishing thread. It is necessary to reproduce this somehow to investigate what is happening. Without it we cannot do anything. So please reporter is there any way how to reproduce this issue? At least sometimes. Or if it happens again please get more thread dumps to see what is changing.
I assume it happens only on specific project/configuration so if possible attach that project here or send it to me directly if it is too big. Also more exact steps how to reproduce would help. If not possible but you are able to reproduce I would have to send you patched modules with logging to get more info. Please try current dev build as we can fix anything in dev build and not in 6.5. (unless we would backport fix)
Re. "Or if it happens again please get more thread dumps to see what is changing." - there is several thread dumps over time in second attachment and they all look exactly the same.
I have done some more investigation of this. Tried with 6.5.1, which still has the issue, so I had a look at some source and tried to see what was actually happening. The problem certainly relates to EarDataObject.refreshSourceFolders() adding itself as a ChangeListener to the Sources (LookupProviderSupport$SourcesImpl) object. That is itself a ChangeListener on WebSources, which is a PropertyListener on SourceRoots, which is notified by AntProjectHelper of configuration changes many many times (even if only one property has actually changed). Since every notification doubles the number of times EarDataObject is added as a listener to LookupProviderSupport$SourcesImpl, the notifying thread quickly takes over the entire CPU when a configuration change is made. Probably Windows' thread scheduling doesn't help much here. I don't think this is actually a true deadlock, it's just that the time to save the configuration increases exponentially each time. Each pass is adding the new listener, which entails copying the ever-growing CopyOnWriteArrayList so that is where the bulk of the work is done, which I guess is why the stack traces always show the thread in ChangeSupport.addChangeListener. LookupProviderSupport$SourcesImpl uses org.openide.util.ChangeSupport, which explicitly says that the same listener object may be added more than once, and will be called as many times as it is added. I'm not clear whether this is necessary in this case. Anyway, putting sources.removeChangeListener (this); before sources.addChangeListener (this); in EarDataObject.refreshSourceFolders seems to fix the problem. Hope that's helpful.
BTW, a single change to the project properties resulted in 16k instances of the EarDataObject as a listener on LookupProviderSupport$SourcesImpl.
Thanks for investigation. I will pass this to J2EE.
File is j2ee.ddloaders/src/org/netbeans/modules/j2ee/ddloaders/app/EarDataObject.java. No idea what is corresponding subcomponent.
Listener problem fixed in df8c0030a6f3. I was wondering how is nobody else had this problem before. The only way to reproduce it was to add application.xml from EAR project to Web project which does not make much sense, no? Anyway, fixed. Thanks you all guys for help.
Integrated into 'main-golden', will be available in build *200903251400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/df8c0030a6f3 User: David Konecny <dkonecny@netbeans.org> Log: #158807 - Netbeans hangs on edit of project properties "Saving project data"
I met the same problem in 6.8. Product Version: NetBeans IDE 6.8 (Build 200912041610) Java: 1.6.0_15; Java HotSpot(TM) Client VM 14.1-b02 System: Linux version 2.6.31-21-generic running on i386; UTF-8; zh_TW (nb) Userdir: /home/kiang/.netbeans/6.8 When editing the 'Properties' of 'Include Path', after clicking 'OK' then the screen keep in 'Saving project data' for a long time and I must kill the process manually. I'm using it under Ubuntu 9.10.
(In reply to comment #16) > When editing the 'Properties' of 'Include Path' You mean a PHP project, right? This is another issue, in Java EE area (moreover fixed more than a year ago). Issue you meant is already fixed, use the development build. Thanks.
Yes, a PHP project. I'll try to use development build.