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.
nb-build 200409200200 + me20040920 I worked with the ide. I had few projects opened. After exit and restart the deadlock occured. see attached messages.log there is IOException see threaddump
Created attachment 17794 [details] last part of messages.log
Created attachment 17795 [details] thread dump
i was able to reproduce it two times with the userdir third time the ide started normally
Problem in J2ME modules. They have no category in issuezilla => closing as INVALID.
wrong choice. We have category for j2me - reopening and reaasignig
reassigning to 3rd-party/j2me
- this is probably called from Explorer when some node is drawn: JavaDataObject.createCookie(JavaParser.class) calls initializeParsingSupport() that requires CloneableEditorSupport.getDocument() - at the same time the same document is beeing opened in editor: BaseDocument.runAtomicAsUser() calls J2MEEditorSupport.loadFromStreamToKit() that requires JavaDataObject.getCookie(EditorCookie.class) and this somehow calls JavaDataObject.initializeParsingSupport() So this is the deadlock and I don't know how to avoid it in J2ME stuff. I think that requesting EditorCookie during J2MEEditorSupport.loadFromStreamToKit() is legitimate (please correct me if I am wrong)
happend again with build 0922, attaching thread dump. I just left open IDE for maybe hour when I was doing something else and then I wanted to return. Increasing priority 'cause it happens too often
Created attachment 17808 [details] thread dump
The problem is that initializeParsingSupport cannot be called under CookieSet.CookieEntry locked if the repository is not locked first. We have solved this for JavaDataObject by overriding getCookie method and starting MDR transaction if the createCookie is going to be called for certain types of cookies. However in this stacktrace FilterNode.getCookie seems to be involved. So I don't know how this could be solved. CC'ing Yarda, maybe he can help.
JavaDataObject.getCookie override is wrong fix. As it can be bypassed by NodeLookup (sorry, my improvent in 3.6). Btw. this can happen without kjava as well. Just call item = yourNode.getLookup().lookupItem(yourCookie.class) in another thread lock mdr and then call item.getInstance(). that will deadlock. You may want to write a test for that... The only, but straight forward fix, I can imagine is to not do anything in cookies' constructors. Let them be initialized later lazily when their first method is called.
See also related issue 48820.
Fixed. Checking in src/org/netbeans/modules/java/JavaDataObject.java; /cvs/java/src/org/netbeans/modules/java/JavaDataObject.java,v <-- JavaDataObject.java new revision: 1.195; previous revision: 1.194 done Checking in src/org/netbeans/modules/java/JavaNode.java; /cvs/java/src/org/netbeans/modules/java/JavaNode.java,v <-- JavaNode.java new revision: 1.121; previous revision: 1.120 done Checking in src/org/netbeans/modules/java/JavaParserGlue.java; /cvs/java/src/org/netbeans/modules/java/JavaParserGlue.java,v <-- JavaParserGlue.java new revision: 1.52; previous revision: 1.51 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/java/codesync/SourceConnectionSupport.java; /cvs/java/src/org/netbeans/modules/java/codesync/SourceConnectionSupport.java,v <-- SourceConnectionSupport.java new revision: 1.25; previous revision: 1.24 done
What exactly is the fix? Not adding listener to SourceElement which should be added, but as the feature does not work now, it is ok, if not added? Unbelievable.
Created attachment 18050 [details] thread dump
Not sure if this is the same issue, but i'm attaching a new deadlock-dump that occurred using Beta2 install when opening a file via 'alt+G' editor shortcut. Treating as this issue because deadlock is still being caused in part by conflict between mdr and JavaDataObject.getCookie call described by Adam Sotona above.
This is fixed. It was fixed after Beta2 was released, so you will need to get the newest dev build to get the fix.
Lukasi, can you verify this issue, please? Thanks.
closing as verified - I don't know how to reproduce but it's out of my radar for now. I do expect that it was fixed long time ago because I haven't seen it nevermore...