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.

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

Deadlock detection on multi thread sizedqueue access not consistent with MRI #2534

Closed
jsvd opened this issue Jan 28, 2015 · 4 comments
Closed

Comments

@jsvd
Copy link
Contributor

jsvd commented Jan 28, 2015

In MRI Ruby, having 2 threads - one pulling/one pushing - acessing a SizeQueue will raise a Deadlock exception if the consumer thread dies. However, in jruby, it will hang forever:

q = SizedQueue.new(5)

thread1 = Thread.new do
  loop { q.push 1 }
end

thread2 = Thread.new do
  q.pop
end

thread1.join
thread2.join

First mri raises exception, then jruby "hangs"

% rvm 2.2.0,jruby do ruby meh.rb
meh.rb:11:in `join': No live threads left. Deadlock? (fatal)
    from meh.rb:11:in `<main>'


^C%
%

Is this deliberate and a choice made on jruby side? or is it a bug?

@jsvd jsvd changed the title Deadlock detection on multi thread sizedqueue access not consistent Deadlock detection on multi thread sizedqueue access not consistent with MRI Jan 28, 2015
@rtyler
Copy link

rtyler commented Jan 30, 2015

@jsvd Based on your script using RVM, I'm assuming you're using JRuby 1.7.x, but which version specifically? It probably doesn't matter too much bit it's useful

@jsvd
Copy link
Contributor Author

jsvd commented Jan 30, 2015

@rtyler jruby-1.7.18, same problem occured w/ jruby 9000.dev-SNAPSHOT (2.1.2p142) 2014-10-21 c34c031 Java HotSpot(TM) 64-Bit Server VM 25.20-b23 on 1.8.0_20-b26 [darwin-x86_64]

@anup1710
Copy link

anup1710 commented Apr 15, 2019

@jsvd / @enebo - It is may be related with MRI bug which got fixed in ruby 2.5.5

with below change

Jruby 9.2.6.0 still stucks with puma when such scenario occurs and in MRI its handled. refer: puma/puma#1744

@headius
Copy link
Member

headius commented Apr 16, 2019

The original report was about us not dying when there's a deadlock, which is difficult to do since we can't necessarily tell that all threads are stopped (the JVM has many threads unrelated to Ruby). It may be possible to detect that all normal Ruby threads are stopped, but since we live within the JVM they may be waiting for something happening outside JRuby; killing the process would be inappropriate in that case.

Notice that even the CRuby error questions whether the "No live threads left" actually means "Deadlock". They pessimistically kill the process when they have no threads to run and they all seem to be waiting on locks.

If some library or app is causing all threads to permanently block, this is a bug in that library or app. I do not consider this a bug in JRuby. The JVM itself does not error out and shut down when all threads are stopped, because it's impossible to know if something outside those threads (signal handling, object finalization, IO) might allow some thread to keep running.

@anup1710 The issues you point out seem to be related to internal bugs in CRuby's Queue implementation (entirely different code than in JRuby) or issues with locks and forking, which is not supported in JRuby. Thank you for investigating!

I am going to just close this since we're not planning to implement CRuby-style deadlock detection. If you want to see the deadlocked threads, you can use JVM mechanisms like capturing a thread dump (which sometimes will actually show which threads are deadlocked).

@headius headius closed this as completed Apr 16, 2019
@headius headius added this to the Won't Fix milestone Apr 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants