Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

JRuby hangs when not using "--dev" mode #4271

Closed
gettalong opened this issue Nov 8, 2016 · 4 comments
Closed

JRuby hangs when not using "--dev" mode #4271

gettalong opened this issue Nov 8, 2016 · 4 comments
Milestone
Invalid or Duplicate

Comments

@gettalong
Copy link

Environment

  • jruby 9.1.5.0 (2.3.1) 2016-09-07 036ce39 Java HotSpot(TM) 64-Bit Server VM 25.91-b14 on 1.8.0_91-b14 +jit [linux-x86_64]
  • Linux host 4.4.0-25-generic LocalContextScope documentation improvement #44-Ubuntu SMP Fri Jun 10 18:19:48 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
  • JRuby installed via RVM, no additional configuration done except for "gem install simplecov"

Expected Behavior

The test suite of HexaPDF should run without problems.

To reproduce:

  • git clone git@github.com:gettalong/hexapdf.git
  • rake test

Actual Behavior

The test suite hangs, with the JRuby process not consuming any CPU time. Using jstack the following backtrace is shown (only the top few lines from the main thread):

"main" #1 prio=5 os_prio=0 tid=0x00007f0b8400c800 nid=0x7ca4 waiting on condition [0x00007f0b8b33d000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000e171ad68> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:403)
        at org.jruby.ext.fiber.FiberQueue$1.run(FiberQueue.java:54)
        at org.jruby.ext.fiber.FiberQueue$1.run(FiberQueue.java:51)
        at org.jruby.RubyThread.executeTask(RubyThread.java:1464)
        at org.jruby.ext.fiber.FiberQueue.pop(FiberQueue.java:128)
        at org.jruby.ext.fiber.FiberQueue.pop(FiberQueue.java:106)
        at org.jruby.ext.fiber.ThreadFiber.exchangeWithFiber(ThreadFiber.java:112)
        at org.jruby.ext.fiber.ThreadFiber.resume(ThreadFiber.java:90)
        at org.jruby.ext.fiber.ThreadFiber$INVOKER$i$0$0$resume.call(ThreadFiber$INVOKER$i$0$0$resume.gen)

It works sometimes but not always when running rake with JRUBY_OPTS=--dev. It is also hard to narrow it down to specific minitest SEED values.

Instead of the whole test suite, the following command also produces the error:

$ ruby -Ilib:test test/hexapdf/image_loader/test_png.rb
@headius
Copy link
Member

headius commented Nov 8, 2016

--dev may pass more often simply because it doesn't run as fast or cause as much contention. If it's not 100% working with that flag, we'll ignore it for now.

The thread dump you provide shows that it's waiting on a fiber. Do you see the object 0x00000000e171ad68 anywhere else in the thread dump? If not, it may mean the target fiber died without notifying its parent thread.

I have not been able to reproduce locally with any seed, running on JRuby 9.1.6.0 (master).

@gettalong
Copy link
Author

gettalong commented Nov 8, 2016 •
edited

No, this ID doesn't show up anywhere else in the jstack output.

@gettalong
Copy link
Author

I have now installed "jruby 9.1.6.0-SNAPSHOT (2.3.1) 2016-11-08 cb5a7be" using rvm install jruby-head.

Now I use while true; do ruby -Ilib:test test/hexapdf/image_loader/test_png.rb ; done to let it run until it hangs. It usually takes 2-5 invocations until this occurs. Rerunning with the seed value that produced the hanging results in a run without hanging.

@gettalong
Copy link
Author

Not reproducible anymore with jruby 9.4.0.0, so I'm closing this.

@enebo enebo added this to the Invalid or Duplicate milestone Oct 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Invalid or Duplicate
Development

No branches or pull requests
3 participants
@gettalong @headius @enebo