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.
Created attachment 101524 [details] thread dump Product Version: NetBeans IDE Dev (Build maven-dev-203-on-100813) Java: 1.6.0_20; Java HotSpot(TM) 64-Bit Server VM 16.3-b01-279 System: Mac OS X version 10.6.4 running on x86_64; MacRoman; en_US (nb) Userdir: /Users/tomas/.netbeans/dev --------- thread dump attached
Created attachment 101528 [details] The same, in plain text format Please do not use strange formats when plain text would suffice.
The IDE was turning on Maven support modules, so may be specific to FoD, but not necessarily. Is there any way to reproduce this problem? Is there any reason to believe it is specific to the maven-dev branch (I don't see any reason based on the thread dump)? Are you intentionally running the Server VM? The EQ thread is not blocked but looks busy. Was the CPU still running or not? The activity looks to be in JAX-WS, not Maven per se: "Lookup Dispatch Thread" daemon prio=1 tid=152087000 nid=0x139626000 in Object.wait() [139624000] java.lang.Thread.State: RUNNABLE at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.netbeans.modules.websvc.jaxws.light.JAXWSLightSupportAccessor.<clinit>(JAXWSLightSupportAccessor.java:61) "FoD Processor" daemon prio=1 tid=102c44000 nid=0x14f8a2000 in Object.wait() [14f89e000] java.lang.Thread.State: RUNNABLE at org.netbeans.modules.websvc.jaxws.light.api.JAXWSLightSupport.<clinit>(JAXWSLightSupport.java:81) My suspicion is that this variant of the accessor pattern is prone to class initialization deadlocks - here two threads are simultaneously attempting to initialize JAXWSLightSupport and JAXWSLightSupportAccessor, where each has a static initializer referring to the other.
cannot reproduce any more. I did some testing in maven-dev build (had open couple maven projects) , and then wanted to open web project (i work normally in 6.9.1) . Cannot give further information since it is not reproducible for me :(
> My suspicion is that this variant of the accessor pattern is prone to class initialization deadlocks I agree, the pattern looks suspicious. However, we use the same pattern (not only with JAXWSLightSupport) in multiple places. If the pattern were incorrect we would need to fix (synchronize static initializers) all usages. Closing as "works for me" as this is not a deadlock in fact. If another similar issue, or deadlock, is observed, we'll need to look at this pattern seriously.
Oops, I found (wrote a simple test case) this variant is really Deadlock prone.
Fixed: http://hg.netbeans.org/web-main/rev/afda9bbf70ee
Integrated into 'main-golden', will be available in build *201008210001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/afda9bbf70ee User: mkuchtiak@netbeans.org Log: #189679: fixed deadlock in Accessor pattern implementation