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 deadlocked in the editor while editing a java file, might have been waiting on code completion, or following a source link, can't remember. Trace attached. Lastest NB 5.5 code.
Created attachment 29827 [details] dead lock stack dump
I notice a very interesting part of the stack dump includes this stack frame in the AWT thread: "at org.netbeans.modules.j2ee.ejbcore.ui.logicalview.ejb.action.EJBActionGroup.enable(EJBActionGroup.java:82)" I have _no_ ejb projects open and I believe in this IDE session, I have _never_ had an EJB project open. It is troublesome to me that under such circumstances the ejb module has been able to attach a listener anyway.
Another interesting observation. This isn't a deadlock because while I was typing in all this information, it looks like my IDE finished whatever it was doing and woke up again. My comment Re: EjbActionGroup still holds though. Something went haywire. I am moving this to Ejb for them to investigate first.
Assigning to ejb...
Looks like something from j2ee verification?
Consulted with abadea; indeed it looks like a performance problem than a deadlock. There are a few threads waiting to start MDR transaction, the lock is being held by "Error Annotation Queue" thread (non-J2EE stuff). Probably not a P2 if not easily reproducible, reassigning to javacore for evaluation. Interesting part of the thread dump: - locked <0xe19b4af8> (a org.netbeans.modules.javacore.jmiimpl.javamodel.ResourceImpl$ErrorList) at org.netbeans.modules.javacore.jmiimpl.javamodel.ResourceImpl$ErrorList.size(ResourceImpl.java:1473) at org.netbeans.modules.java.JavaEditor.refreshAnnotations(JavaEditor.java:416) at org.netbeans.modules.java.JavaEditor.access$400(JavaEditor.java:89) at org.netbeans.modules.java.JavaEditor$2.run(JavaEditor.java:262) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:493) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:926)
I do not see any deadlock. More precisely - "Hints RP" thread holds MDR read transaction and waiting for the ResourceImpl$ErrorList lock, which is held by "Error Annotation Queue" thread.
Marking as INVALID, "Error Annotation Queue" thread is running, no deadlock is visible thread dump.
How can this be invalid? The entire IDE GUI froze in place for 5 minutes. This is considered acceptable behavior??? Also, there is an MDR transaction on the AWT thread. Is that valid usage?
5 minutes? It is very long, new information. From the information provided I can only say that thread "Error Annotation Queue" run too long, more precisely javac compilation takes ages. More thread dumps should confirm this hypothesis. What about exceptions in messages.log? Maybe OutOfMemory? Did your CPU work when you made a thread dump? > Also, there is an MDR transaction on the AWT thread. Is that valid usage? It is bad practice, but IMO not forbidden. As you wrote, it affects UI responsivness in case of long lasting trasanction. For the time being, we have to wait for addition information. Note: We see also another solution, that "Hints RP" in JavaHintsProvider.getHints() will not call ErrorList inside MDR transaction. This solution is not straight forward and IMO it is risky for 5.5. Changing subject to reflect current knowledge.
I guess you are waiting for more information from me, but I don't know what more I can tell you. While the IDE was frozen, the rest of my system was very responsive, so whatever was happening consumed very little CPU, if any at all. I have often found that code completion is not fast enough (in other words, if I have to wait more than 1-2 seconds for it to pop up, I get impatient, hit escape and try something else or type in manually whatever I wanted). I have the same issue with Find Usages and <Ctrl-Click> on a method/class link (or right click | Go To Source) and in this case I think I went from one choice to another since the first didn't react fast enough. The point is that quickly switching between these options, all of which rely on MDR in some way, will cause problems if for some reason a thread blocks when holding the MDR lock. I don't know what more I can tell you exception this was a SunBlade 2500 (Ultrasparc IIIi 1.6 GHz, 2GB RAM, super fast hard disks) running Solaris 10. Not a slow machine by any stretch.
We have to wait for another reports. I isn't reproducible. More thread dumps when IDE is frozen should be good point to start. Also messages.log will help. I cannot still disconfirm OutOfMemory excpetion.
Classes causing this problem are no longer in trunk build after java infrastructure redesign.