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.
If recent selected node is one from Jini browser children then it deadlocks IDE during startup. I think that it's NbPresenter error as setVisible() should be thread safe method. (Moreover it's called in non modal mode).
Created attachment 8544 [details] The deadlock
Created attachment 8545 [details] The deadlock
Discussed with Marek Slama and concluded that a dialog returned by TopManager,createDialog() should have thread safe setVisible(true) implementation.
Two things: 1.NbPresenter.show() is safe because it is called from AWT thread. However it must be synchronous so invokeAndWait() is used. 2.From thread dump you provided is not clear where deadlock exactly is ie. where (probably) nodes are locked. The problem is caused by calling NbPresenter.show() from some node lock which is held at the same time by AWT thread. It seems FolderChildren.findChild() is waiting. From thread dump the only solution I see is to avoid calling NbPresenter.show() from Default Request Processor but use invokeLater(). In AWT thread tree in ExplorerPanel is expanded and it calls findChild() synchronously and it cannot be split. Any other idea?
Sorry: The problem is caused by calling NbPresenter.show() from some node lock which is held at the same time by AWT thread. It seems FolderChildren.findChild() is waiting. Should be: The problem is caused by calling NbPresenter.show() from findChild() when findChild() helds lock which is AWT thread waiting for.
Fixed comment: When NbPresenter.show() is not called from AWT thread it uses invokeAndWait() to call super.show() in AWT thread. (And unfortunately call of invokeAndWait() can be dangerous.) The problem is caused by calling NbPresenter.show() from findChild() when findChild() helds lock which is AWT thread waiting for. From thread dump the only solution I see is to avoid calling NbPresenter.show() from Default Request Processor but use invokeLater(). In AWT thread tree in ExplorerPanel is expanded and it calls findChild() synchronously and it cannot be split. Any other idea?
invokeLater may help. Would it work properly with modal dialogs>
It should be ok when you do not need user response synchronously in current non AWT thread (because code after invokeLater() is performed further). But if you need return value to decide eg code flow if(ret) {} else {} in current thread I am afraid it is not generally solvable/safe.
Created attachment 8666 [details] Modality vs. blocking semantics test
Attached test proves that setvisible(true) call is for: - modal dialogs blocking - non-modal non-bloacking So I think you can safelly add invoke later for non-modal dialogs.
Yes when dialog is non modal show() returns immediatelly. It means that in case of non modal dialog NbPresenter.show() could use invokeLater() and not invokeAndWait(). Is such solution OK?
I'm fine with it.
Fixed in main trunk. show() is called asynchronously for non modal dialogs to avoid deadlock. Modified: core/src/org/netbeans/core/NbPresenter.java r.1.76
Just an off the wall comment here. invokeAndWait is not so much dangerous as it is revealing. When it does not work it often indicates some other issue. I recently deadlocked because I was calling invokeAndWait from a synchronized method of a JFrame. My method did not need to be synchronized so it was an easy solution. I can see NB is much more complicated though. It would be interesting to see who is holding the lock on the current object before you call invoke and wait on it, just as a test.
verified