Possible hang in ServiceManagerTest

[GoogleCodeExporter]

One time, when running the tests of the JDK5 backport[*] -- no, I don't know if 
the JDK5-ness (e.g., ArrayDeque -> LinkedList) is relevant -- 
ServiceManagerTest appeared to hang. jstack output is attached. I don't know if 
there were any exceptions or other hints of a cause. (Certainly our Maven test 
output always has exceptions in it; I didn't see if any looked related, and 
I've since overwritten the output files :\) The interesting part of the stacks 
is below.

The test worked fine the next time I ran it, and it worked fine when I made the 
equivalent internal change and ran 10x against the normal internal JDK with the 
normal tools.

I could believe that we hit a crazy VM bug or something, but in case there's 
anything actually wrong in ServiceManager or its test, I figured I'd file this 
bug.

  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 com.google.common.util.concurrent.Uninterruptibles.awaitUninterruptibly(Uninterruptibles.java:55)
  at com.google.common.util.concurrent.ServiceManagerTest$4.failure(ServiceManagerTest.java:365)
  at com.google.common.util.concurrent.ServiceManager$ServiceManagerState$5.call(ServiceManager.java:689)
  at com.google.common.util.concurrent.ServiceManager$ServiceManagerState$5.call(ServiceManager.java:687)
  at com.google.common.util.concurrent.ListenerCallQueue.run(ListenerCallQueue.java:118)
  at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
  at com.google.common.util.concurrent.ListenerCallQueue.execute(ListenerCallQueue.java:86)
  at com.google.common.util.concurrent.ServiceManager$ServiceManagerState.executeListeners(ServiceManager.java:700)
  at com.google.common.util.concurrent.ServiceManager$ServiceManagerState.transitionService(ServiceManager.java:671)
  at com.google.common.util.concurrent.ServiceManager$ServiceListener.failed(ServiceManager.java:774)
  at com.google.common.util.concurrent.AbstractService$9.call(AbstractService.java:484)
  at com.google.common.util.concurrent.AbstractService$9.call(AbstractService.java:482)
  at com.google.common.util.concurrent.ListenerCallQueue.run(ListenerCallQueue.java:118)
  at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
  at com.google.common.util.concurrent.ListenerCallQueue.execute(ListenerCallQueue.java:86)
  at com.google.common.util.concurrent.AbstractService.executeListeners(AbstractService.java:433)
  at com.google.common.util.concurrent.AbstractService.startAsync(AbstractService.java:180)
  at com.google.common.util.concurrent.ServiceManager.startAsync(ServiceManager.java:287)
  at com.google.common.util.concurrent.ServiceManagerTest.testListenerDeadlock(ServiceManagerTest.java:371)

[*] at 
http://code.google.com/p/guava-libraries/source/detail?r=566894361b48cec7d391127
fe4b0f9547b4549c6&name=jdk5-backport-master

Original issue reported on code.google.com by cpov...@google.com on 7 Apr 2014 at 5:42

Attachments:

• ServiceManagerTest.stack

[GoogleCodeExporter]

looks like a bug in the test.  though a pretty crazy one.  I doubt the backport 
change you made would make a difference.  Though possibly the recent 
ListenerCallQueue changes made this race more likely (since there is slightly 
less locking going on)

The failure callback was supposed to run on another thread, but it looks like 
thread scheduling allowed notifyFailed to run prior to when the original 
executeListeners call from Service.startAsync call returned.  So the failure 
listeners ended up running on the wrong thread (in particular it ran on the 
test thread).  The fix is to introduce another synchronization point between 
the background thread and the main test thread to make sure that all started 
callbacks have fired prior to calling notifyFailed.... phew!

Original comment by lu...@google.com on 7 Apr 2014 at 5:57

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:09

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:17

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:07

• Added labels: Restrict-AddIssueComment-Commit