Community
Participate
Working Groups
Sorry to report this against an old version, and please resolve if this has been fixed in newer versions which should then urge us to finally upgrade... We're still using 3.16.100v20201030-1916 and are experiencing an occasional deadlock during container shutdown. Here are the two competing threads: Thread [main] (Suspended) waiting for: AtomicReference<V> (id=24) Object.wait(long) line: not available [native method] EquinoxBundle$SystemBundle$EquinoxSystemModule(SystemModule).waitForStop(long) line: 173 EquinoxBundle$SystemBundle.waitForStop(long) line: 306 Equinox.waitForStop(long) line: 217 EclipseStarter.shutdown() line: 457 EclipseStarter.run(String[], Runnable) line: 274 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 Main.invokeFramework(String[], URL[]) line: 653 Main.basicRun(String[]) line: 590 Main.run(String[]) line: 1461 Main.main(String[]) line: 1434 and Thread [Framework stop - Equinox Container: 8a2dbb34-2363-442e-84e4-4e7b4ea1ff4f] (Suspended) Unsafe.park(boolean, long) line: not available [native method] Unsafe.park(boolean, long) line: 1079 LockSupport.park(Object) line: 175 ReentrantLock$NonfairSync(AbstractQueuedSynchronizer).parkAndCheckInterrupt() line: 836 ReentrantLock$NonfairSync(AbstractQueuedSynchronizer).acquireQueued(AbstractQueuedSynchronizer$Node, int) line: 870 ReentrantLock$NonfairSync(AbstractQueuedSynchronizer).acquire(int) line: 1199 ReentrantLock$NonfairSync.lock() line: 245 ReentrantLock.lock() line: 321 ZipBundleFile(CloseableBundleFile<E>).close() line: 340 ClasspathEntry.close() line: 257 ClasspathManager.close() line: 152 EquinoxClassLoader(ModuleClassLoader).close() line: 457 BundleLoader.close() line: 359 EquinoxContainerAdaptor.invalidateWiring(ModuleWiring, ModuleLoader) line: 264 ModuleWiring.invalidate0(boolean) line: 363 ModuleWiring.unload() line: 352 ModuleContainer.unloadModules() line: 1253 ModuleContainer.close() line: 1197 EquinoxBundle$SystemBundle$EquinoxSystemModule(SystemModule).stop(Module$StopOptions...) line: 220 EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run() line: 220 Thread.run() line: 838 The former waits on the AtomicReference bound to variable stopEvent. The latter tries to obtain the openLock which is held by the former thread. The latter thread would notify the monitor the former thread is waiting on in the finally block that follows in the stop(...) method, but it doesn't reach there because it is hung up at the lock. This avoids clean shut-down which in turn causes our tests to hang sporadically.
Can you get a jstack of the process when it is hung so we can get a complete picture of the locks involved here. The only way I can see this happening is if an InputStream from a bundle entry got leaked and not closed. We've recently moved to github for the source/issues of the project. Could you move this to an issue at https://github.com/eclipse-equinox/equinox.framework?
This is now being tracked at https://github.com/eclipse-equinox/equinox.framework/issues/50.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
