Community
Participate
Working Groups
Created attachment 187796 [details] 3 thread dumps in zip file Carl told me some "fixes went in" to fix these hangs, but ... still hangs (I'm guessing). Not sure if the fix just made another problem apparent ... or, if fix was incomplete? But, in either case, I kept my eye on the build, and when this suite had been running for about 50 minutes, figured it was probably hung and snagged 3 thread dumps (attached in zip) approximately a minute apart. Hope they help,
The thread Worker-3 is stuck. 3XMTHREADINFO "Worker-3" J9VMThread:0xC407DE00, j9thread_t:0x082FDC68, java/lang/Thread:0xC7981CD8, state:CW, prio=5 3XMTHREADINFO1 (native thread ID:0x3D42, native priority:0x5, native policy:UNKNOWN) 3XMTHREADINFO2 (native stack address range from:0xC41BF000, to:0xC4200000, size:0x41000) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at java/lang/Object.wait(Native Method) 4XESTACKTRACE at java/lang/Object.wait(Object.java:196) 4XESTACKTRACE at org/eclipse/core/internal/jobs/ThreadJob.waitForRun(ThreadJob.java:269) 4XESTACKTRACE at org/eclipse/core/internal/jobs/ThreadJob.joinRun(ThreadJob.java:199) 4XESTACKTRACE at org/eclipse/core/internal/jobs/JobManager.yieldRule(JobManager.java:1398) 4XESTACKTRACE at org/eclipse/core/internal/jobs/InternalJob.yieldRule(InternalJob.java:600) 4XESTACKTRACE at org/eclipse/core/runtime/jobs/Job.yieldRule(Job.java:709) 4XESTACKTRACE at org/eclipse/wst/common/componentcore/internal/builder/DependencyGraphImpl.waitForAllUpdates(DependencyGraphImpl.java:711) 4XESTACKTRACE at org/eclipse/wst/common/componentcore/internal/builder/DependencyGraphImpl.getReferencingComponents(DependencyGraphImpl.java:124) 4XESTACKTRACE at org/eclipse/wst/common/componentcore/internal/builder/DependencyGraphImpl.getReferencingComponents(DependencyGraphImpl.java:115) 4XESTACKTRACE at org/eclipse/wst/common/componentcore/internal/resources/VirtualComponent.getReferencingComponents(VirtualComponent.java:577) 4XESTACKTRACE at org/eclipse/jst/j2ee/project/EarUtilities.getReferencingEARProjects(EarUtilities.java:274) 4XESTACKTRACE at org/eclipse/jst/j2ee/componentcore/J2EEModuleVirtualComponent.calculateManifestReferences(J2EEModuleVirtualComponent.java:370) 4XESTACKTRACE at org/eclipse/jst/j2ee/componentcore/J2EEModuleVirtualComponent.cacheManifestReferences(J2EEModuleVirtualComponent.java:360) 4XESTACKTRACE at org/eclipse/jst/j2ee/componentcore/J2EEModuleVirtualComponent.getReferences(J2EEModuleVirtualComponent.java:169) 4XESTACKTRACE at org/eclipse/jst/j2ee/internal/web/classpath/WebAppLibrariesContainer.computeReferences(WebAppLibrariesContainer.java:158) 4XESTACKTRACE at org/eclipse/jst/common/jdt/internal/classpath/FlexibleProjectContainer.computeClasspathEntries(FlexibleProjectContainer.java:200) 4XESTACKTRACE at org/eclipse/jst/j2ee/internal/web/classpath/WebAppLibrariesContainer.computeClasspathEntries(WebAppLibrariesContainer.java:188) 4XESTACKTRACE at org/eclipse/jst/j2ee/internal/web/classpath/WebAppLibrariesContainer.computeClasspathEntries(WebAppLibrariesContainer.java:177) 4XESTACKTRACE at org/eclipse/jst/common/jdt/internal/classpath/FlexibleProjectContainer.<init>(FlexibleProjectContainer.java:120) 4XESTACKTRACE at org/eclipse/jst/j2ee/internal/web/classpath/WebAppLibrariesContainer.<init>(WebAppLibrariesContainer.java:66) 4XESTACKTRACE at org/eclipse/jst/j2ee/internal/web/classpath/WebAppLibrariesContainer.refresh(WebAppLibrariesContainer.java:146) 4XESTACKTRACE at org/eclipse/jst/common/jdt/internal/classpath/FlexibleProjectContainer$Listener.resourceChanged(FlexibleProjectContainer.java:495) In bug 331719, it looks like we were slightly off on the placement of one check.
We added a check in WebAppLibrariesContainer.refresh(boolean), which calls refresh(). This thread goes into refresh() directly, thus missing the deadlock avoidance check in bug 331719
Moving to Java EE Tools, since WebAppLibraryContainer is located there.
As Carl said, I missed one place in which I should put the check. I'm working on it.
Created attachment 187890 [details] Patch
approved for additional PMC review. The previous fix wasn't complete, - any classpath container access requires this check - including creating a new instance.
1. Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. Deadlocks might occur during startup while classpath containers are installed. This is a complement of bug 331719 2. Is there a work-around? If so, why do you believe the work-around is insufficient? The only work-around is restart eclipse 3. How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? The fix was tested running the existing JEE JUnits and by hand 4. Give a brief technical overview. Who has reviewed this fix? Same validation as in bug 331719 was added in Web classpath containers to check if the state of the dependency graph is current. If it is not, then do not call a deadlock-prone code in the dependency graph until it is updated. The fix was reviewed by Chuck Bridgham 5. What is the risk associated with this fix? Medium
excellent! Thanks.
Committed to R3_2_maintenance for WTP 3.2.3
