Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 335645

Summary: hang in unit tests: o.e.jst.jsf.core.tests
Product: [WebTools] WTP Java EE Tools Reporter: David Williams <david_williams>
Component: jst.j2eeAssignee: Roberto Sanchez Herrera <shr31223>
Status: RESOLVED FIXED QA Contact: Chuck Bridgham <cbridgha>
Severity: normal    
Priority: P3 CC: carlin.rogers, ccc, ian.trimble, jsholl, raghunathan.srinivasan, shr31223
Version: 3.2Flags: david_williams: pmc_approved+
shr31223: pmc_approved? (raghunathan.srinivasan)
shr31223: pmc_approved? (naci.dai)
deboer: pmc_approved+
shr31223: pmc_approved? (neil.hauge)
shr31223: pmc_approved? (kaloyan)
cbridgha: review+
Target Milestone: 3.2.3   
Hardware: PC   
OS: Windows 7   
Whiteboard: PMC_approved
Bug Depends on: 331719    
Bug Blocks:    
Attachments:
Description Flags
3 thread dumps in zip file
none
Patch ccc: iplog+

Description David Williams CLA 2011-01-27 21:35:00 EST
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,
Comment 1 Carl Anderson CLA 2011-01-28 10:31:57 EST
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.
Comment 2 Carl Anderson CLA 2011-01-28 10:34:38 EST
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
Comment 3 Carl Anderson CLA 2011-01-28 11:07:45 EST
Moving to Java EE Tools, since WebAppLibraryContainer is located there.
Comment 4 Roberto Sanchez Herrera CLA 2011-01-28 11:53:48 EST
As Carl said, I missed one place in which I should put the check. I'm working on it.
Comment 5 Roberto Sanchez Herrera CLA 2011-01-28 17:44:17 EST
Created attachment 187890 [details]
Patch
Comment 6 Chuck Bridgham CLA 2011-02-02 18:51:56 EST
approved for additional PMC review.

The previous fix wasn't complete, - any classpath container access requires this check - including creating a new instance.
Comment 7 Roberto Sanchez Herrera CLA 2011-02-02 19:57:47 EST
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
Comment 8 David Williams CLA 2011-02-02 20:11:26 EST
excellent! Thanks.
Comment 9 Carl Anderson CLA 2011-02-02 23:04:05 EST
Committed to R3_2_maintenance for WTP 3.2.3