Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] deadlock in fileinstall on equinox

Hey All (cross posted as I'm not sure where the answer will come from),

versions: 
- fileinstall 3.4.0
- equinox 3.8.0.v20120529-1548

I'm seeing a deadlock where on first start the fileinstall bundle is getting stuck with itself

as per the following two stack traces:

"Refresh Packages" daemon prio=10 tid=0x00007fc29c0f6800 nid=0x94c waiting on condition [0x00007fc2b9c15000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000000c095f950> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
	at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
	at org.apache.felix.fileinstall.internal.FileInstall.stop(FileInstall.java:171)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:771)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:764)
	at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:510)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:566)
	at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1207)
	at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:326)
	at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
	at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
	- locked <0x00000000c0cbc1f8> (a org.eclipse.osgi.framework.internal.core.PackageAdminImpl)
	at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
	at java.lang.Thread.run(Thread.java:744)
   Locked ownable synchronizers:
	- None

"fileinstall-/home/rotty/AS/liferay-portal/osgi/portal" daemon prio=10 tid=0x00007fc2ac01a000 nid=0x920 waiting on condition [0x00007fc2ba721000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000000c51bd048> (a java.util.concurrent.CountDownLatch$Sync)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
	at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
	at org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:319)
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:674)
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:495)
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)
   Locked ownable synchronizers:
	- None
You can see that the refresh event will never return (to tear down the latch) as long as the FileInstall.stop operation can't get the lock in to directory which it's currently holding during the refresh operation!
What seems strange is that fileinstall is adding itself to the list of bundles to refresh during the findBundlesWithOptionalPackagesToRefresh(toRefresh); call. Is that expected?

Sincerely,
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)


Back to the top