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.
[nb36rc2][jdk 1.5.0beta-2] the form editor was disabled and again enabled. There was some exceptions. See to the attachment for ide.log. The deadlock occured when the form was closed. See to the attachment fot the deadlock threads dump.
Created attachment 14226 [details] ide.log
Created attachment 14227 [details] threads dump
pzajac: next time please always mark deadlock issues w/ THREAD keyword. Thx assigning to pnejedly
need investigation but not a showstopper for NB 3.6 -> promo-D
Evaluation: There is a .java file opened in editor (through JavaDL) and modified. If you enable the form module, loader pool content changes and during revalidation, the form claims ownership of the .java file (as there is a .form file laying nearby). Because there is an existing and valid JavaDO currently owning the file, it have to be invalidated first. Invalidation needs user cooperation as the file is modified (save/discard dialog), but runs on different thread -> invokeAndWait AWT is blocked waiting for some datasystems service so can't proceed with the dialog, DS can't serve AWT as it is waiting for user response -> deadlock
Possible solutions: A) don't allow takeover of modified file - inconsistency - in fact needed only iff AWT blocked B) discard the file - data loss C) rewrite waitFinished to foxtrot-like behaviour when waiting in AWT - unreliable - hell to understand, hell to maintain, too much magic D) A + rescheduled retry - not sure if it would work E) ??? (I'm out of ideas now) CCing gurus...
E) SaveAll before module set change (be on the safe side, new modules can generally cause troubles ;-)
With Yarda, we think about this: post a user dialog, give it timeout to show. If it goes through, save or discard according to user decision. If it doesn't, ban the takeover. Maybe it could be extended with rescheduled retry scheme.
From user point of view I think showing the same dialog as is shown before exit from the IDE when modules are changing with option to saveall or cancel the operation is the best experience I can imagine in this case. Still we need to fix the CES. invokeLater () + wait(5000) is the best way how to get from DataObject.setValid(...) missery. Looking forward to see the test ;-)
I'm for Yarda solution.
Agreed, (E) is safest - make sure everything is saved before you fool with this stuff.
Created attachment 16445 [details] DialogDisplayer(impl).notify enhanced with deadlock detection
I am ready to fix this. I'll do saveAll during enable/disable modules from UI and I am going to apply my patch which prevents the deadlock, when it appears, to last forever.
Checking in src/org/netbeans/core/ui/ModuleBean.java; /cvs/core/src/org/netbeans/core/ui/ModuleBean.java,v <-- ModuleBean.java new revision: 1.33; previous revision: 1.32 done Processing log script arguments... More commits to come... Checking in windows/src/org/netbeans/core/windows/services/DialogDisplayerImpl.java; /cvs/core/windows/src/org/netbeans/core/windows/services/DialogDisplayerImpl.java,v <-- DialogDisplayerImpl.java new revision: 1.5; previous revision: 1.4 done Processing log script arguments... More commits to come... RCS file: /cvs/core/windows/test/unit/src/org/netbeans/core/windows/services/DialogDisplayerImplTest.java,v done Checking in windows/test/unit/src/org/netbeans/core/windows/services/DialogDisplayerImplTest.java; /cvs/core/windows/test/unit/src/org/netbeans/core/windows/services/DialogDisplayerImplTest.java,v <-- DialogDisplayerImplTest.java initial revision: 1.1
cannot reproduce->verified