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.
I played with the toolbars on the toolbar palette, shifting them around heavily and from a certain moment the IDE has frozen. See the attached thread dumps for details. The dumps where taken several tens of seconds after each other. I waited for several minutes and then killed the IDE. So this is perhaps not only a pure performance problem (something taking too long), but a more complicated issue.
Created attachment 14153 [details] 1st thread dump
Created attachment 14155 [details] 2nd thread dump
Created attachment 14156 [details] 3rd thread dump
none of the dumps looks ike a deadlock to me, it's not even in netbeans code at all. It seems like a file was read and parsed. maybe it was some OS related IO problem? happens to me quite often with my notebook and the installed RedHat. Was only Netbeans unresponsive or all applications? I assume you have no steps to reproduce the problem? ;(
oups.
This is easily reproducible on my Windows desktop machine. I didn't try reproducing it on Linux. And org.netbeans.core.windows.view.ui.toolbars.ToolbarConfiguration.readConfig(ToolbarConfiguration.java:197) in the thread dump seems to me to *BE* our code. ;o) OK, don't call it deadlock. Nonetheless the IDE is dead for many minutes, maybe indefinitely...
Ok, now I'm able to reproduce it one has to move the toolabrs around and drop them, then drag it again etc. the porblem is that in updateConfiguration() the initInstance() method is called which keeps adding listeners to DnD, thus over time creating a snowball effect. Will look into it tomorrow. Is most probably in 3.6 as well. (I didn't test it but the affected code is quite old.)
looks bad. Honza, showstopper for 3.6?
Doesn't seem to be reproducible in 3.6.
Switching Version value back to promo-D. Not reproducible in NB36 RC1.
the problem seems to be that ToolbarProcessor.instanceCreate() is called repeatedly and a new listener is added each time. I suppose it has to do with recent changes to XMLDataObject. reassigning for evaluation.
I added some traces to ToolbarProcessor.instanceCreate() and it is called once per toolbar move what looks OK. Pasing back to winsys.
David, if it were ok, I would not transfer it to you! At least in 3.6 it didn't behave like that (I double check right now), so the big question is what is the correct behaviour?
This is side effect of Yarda's fix of issue 40290. *** This issue has been marked as a duplicate of 40290 ***
this not a duplicate of issue 40290. It's caused by an attempt to fix it, but it's not the same thing, reopen
Now I am glad that I did not have to fix the issue 40290 in promo-B.
/cvs/openide/loaders/src/org/openide/loaders/XMLDataObject.java,v <-- XMLDataObject.java new revision: 1.14; previous revision: 1.13 done Processing log script arguments... More commits to come... Checking in openide/test/unit/src/org/openide/loaders/XMLDataObjectTest.java; /cvs/openide/test/unit/src/org/openide/loaders/XMLDataObjectTest.java,v <-- XMLDataObjectTest.java new revision: 1.3; previous revision: 1.2 done Processing log script arguments... More commits to come... Checking in core/windows/src/org/netbeans/core/windows/view/ui/toolbars/ToolbarConfiguration.java; /cvs/core/windows/src/org/netbeans/core/windows/view/ui/toolbars/ToolbarConfiguration.java,v <-- ToolbarConfiguration.java new revision: 1.12; previous revision: 1.11
I verified that the problem does not appear anymore. However hard I tried moving toolbars does not seem to get slower. Milos, you had made a nice printout which has shown that the number of toolbar configuration saves is increasing exponentionally. Can you apply the printout to the latest trunk build and verify that the configuration is saved only once? THX.