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 143932 [details] Thread dump after the deadlock Caused by changeset: 2c66d674a840 user: Jaroslav Tulach <jtulach@netbeans.org> date: Tue Nov 05 10:59:42 2013 +0100 summary: Cannot enable module if one does not have write lock on the module manager. Demonstrates when OSGi module is enabled lazily probably.
Can you please review following change http://hg.netbeans.org/ergonomics/rev/6daad31b75aa ? It seems the easiest way to deal with the deadlock (that so far occurred only in a test). The change also brings the API of Mutex.Privileged closer to JDK's Lock, so I hope it is non-controversial. I've integrated the change to see if it stabilizes the ergonomics build (failed at least five times in a week due to the problem), but I am ready to apply your comments before pushing to main-silver.
The build of ergonomics seems more stable after the change. Five successful runs, two test failures but none related to this deadlock. I think we should proceed with integration.
Integrated into 'main-silver', will be available in build *201401190001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/6daad31b75aa User: Jaroslav Tulach <jtulach@netbeans.org> Log: Issue #240442 can best be solved by waiting only a limited time (e.g. 10s) and then giving up. Adding neccessary methods to Mutex.Privileged.
Jaroslav Tulach, I wish you had used a non-zero timeout value in the other calls to sleep, as I am experiencing NetBeans lockup on startup. This is happening on the Swing thread via the call Mutex.java, line 1257: enter(mutexMode, t, 0);
Is your thread dump the same one as the one attached? E.g. https://netbeans.org/bugzilla/attachment.cgi?id=143932 Or is it slightly different? Please attach it.