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.
There is sometimes a deadlock which is illustrated by attached thread dump. Below is an excerpt from it showing the opposite orders of locking in 2 execution paths through mdr code. Thus there is a deadlock when these paths happen to be executed simultaneously on 2 different threads. The path executed in the excerpt below on "AWT-EventQueue-1": A1. took the lock <0x0578a548> A2. after that it came to the ExclusiveMutex.enter() where it encountered "artificial" lock (ie. the logic the ExclusiveMutex's enter() and leave() implement) and started to wait until the thread that has set this "artificial" lock come and release it At the same time the code that is executed on the thread "Parsing Event Queue" in the excerpt below: B1. set the "artificial" lock at BaseObjectHandler.java:303 as part of execution of BaseObjectHandler.refImmediatePackage() method right before proceeding to NBMDRepositoryImpl.getHandler call at BaseObjectHandler.java:305 B2. after that it came to the point where it tried to get lock <0x0578a548> Ie. deadlock : B2 waits for the lock that is taken at A1 A2 waits for the "artificial" lock that is set at B1 [..cut..] "Parsing Event Queue" daemon prio=2 tid=0x2a2b4db0 nid=0xe94 waiting for monitor entry [0x330af000..0x330afae8] at org.netbeans.mdr.NBMDRepositoryImpl.getHandler(NBMDRepositoryImpl.java:595) - waiting to lock <0x0578a548> (a org.netbeans.mdr.NBMDRepositoryImpl$FacilityCache) at org.netbeans.mdr.NBMDRepositoryImpl.getHandler(NBMDRepositoryImpl.java:611) at org.netbeans.mdr.handlers.BaseObjectHandler.refImmediatePackage(BaseObjectHandler.java:305) ==================== B1. at BaseObjectHandler.java:303 the "artificial" lock of ExclusiveMutex was set ==================== at org.netbeans.modules.javacore.jmiimpl.javamodel.SemiPersistentElement.isValid(SemiPersistentElement.java:63) [..cut..] "AWT-EventQueue-1" prio=6 tid=0x291e75d0 nid=0xec0 in Object.wait() [0x29b7f000..0x29b7fa68] at java.lang.Object.wait(Native Method) - waiting on <0x0618ac90> (a org.netbeans.modules.javacore.ExclusiveMutex) at java.lang.Object.wait(Object.java:474) at org.netbeans.modules.javacore.ExclusiveMutex.enter(ExclusiveMutex.java:133) - locked <0x0618ac90> (a org.netbeans.modules.javacore.ExclusiveMutex) at org.netbeans.mdr.NBMDRepositoryImpl.beginTrans(NBMDRepositoryImpl.java:228) at org.netbeans.mdr.handlers.BaseObjectHandler._lock(BaseObjectHandler.java:219) at org.netbeans.mdr.handlers.BaseObjectHandler.refImmediatePackage(BaseObjectHandler.java:303) at org.netbeans.mdr.NBMDRepositoryImpl$FacilityCache$HandlerReference.<init>(NBMDRepositoryImpl.java:1408) at org.netbeans.mdr.NBMDRepositoryImpl$FacilityCache.put(NBMDRepositoryImpl.java:1442) at org.netbeans.mdr.NBMDRepositoryImpl.getHandler(NBMDRepositoryImpl.java:665) - locked <0x0578a548> (a org.netbeans.mdr.NBMDRepositoryImpl$FacilityCache) - locked <0x0578a548> (a org.netbeans.mdr.NBMDRepositoryImpl$FacilityCache) at org.netbeans.mdr.NBMDRepositoryImpl.getHandler(NBMDRepositoryImpl.java:614) at org.netbeans.modules.javacore.jmiimpl.javamodel.ImportClassImpl.create(ImportClassImpl.java:51) [..cut..]
Created attachment 32940 [details] thread dump
The problem is the transaction should be started much sooner in AWT-EventQueue - probably MetadataElement.getStartOffset() should start it.
This bug can be fixed on 2 sides: you can either surround your calls to getStartOffset() by MDR transaction or we can add MDR transaction into geStartOffset() method. I implemented the second solution, but I'm not able to reproduce the deadlock and therefore I'm not able to verify the fix. Can you try attached patch? Thanks.
Created attachment 33106 [details] Proposed patch
the deadlock isn't always reproducible. I've also not been able to reproduce it. Anyway i've looked into and tried the patch through the scenario from the original UML bug, and so far it looks good for me. The QA, who are able to reproduce the deadlock, are going to verify the fix once it is in the build.
Patch seems to me correct and is safe.
Fixed in trunk Checking in MetadataElement.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/MetadataElement.java,v <-- MetadataElement.java new revision: 1.73; previous revision: 1.72 done
Checking in MetadataElement.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/MetadataElement.java,v <-- MetadataElement.java new revision: 1.56.4.5.2.3; previous revision: 1.56.4.5.2.2 done
The fix has been ported into the release50_fixes branch. Checking in MetadataElement.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/MetadataElement.java,v <-- MetadataElement.java new revision: 1.67.2.2.2.1; previous revision: 1.67.2.2 done
Reorganization of java component