#141 new
Nathan Sobo

Mysterious intermittent deadlock in threaded mode on ruby 1.9.1-p378

Reported by Nathan Sobo | November 25th, 2010 @ 12:21 PM

It occurs when the reactor tries grabs a mutex to push an operation onto the thread pool's queue in EM.defer.

<internal:prelude>:6:in `lock': deadlock detected (fatal)
    from <internal:prelude>:6:in `synchronize'
    from /Users/nathansobo/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/1.9.1/thread.rb:148:in `push'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/bundler/gems/eventmachine-6c7997798034/lib/eventmachine.rb:996:in `defer'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/gems/thin-1.2.7/lib/thin/connection.rb:54:in `process'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/gems/thin-1.2.7/lib/thin/connection.rb:42:in `receive_data'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/bundler/gems/eventmachine-6c7997798034/lib/eventmachine.rb:195:in `run_machine'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/bundler/gems/eventmachine-6c7997798034/lib/eventmachine.rb:195:in `run'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/gems/thin-1.2.7/lib/thin/backends/base.rb:57:in `start'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/gems/thin-1.2.7/lib/thin/server.rb:156:in `start'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/gems/thin-1.2.7/lib/thin/controllers/controller.rb:80:in `start'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/gems/thin-1.2.7/lib/thin/runner.rb:177:in `run_command'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/gems/thin-1.2.7/lib/thin/runner.rb:143:in `run!'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/gems/thin-1.2.7/bin/thin:6:in `<top (required)>'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/bin/thin:19:in `load'
    from /Users/nathansobo/.rvm/gems/ruby-1.9.1-p378/bin/thin:19:in `<main>'`

There's reference to this exact same stack trace in another (resolved) ticket:
https://thin.lighthouseapp.com/projects/7212/tickets/118-threaded-m...

I am using an EventMachine release that incorporates the supposed fix to that issue: ref 6c7997798034

I'm confused as to how pushing onto a stdlib queue could ever cause a deadlock. I don't understand what other blocked thread could possibly be holding this mutex, because the critical section doesn't grab any locks or invoke any code. Am I missing something big?

Perhaps this is the wrong forum to bring this up, but I figured I'd start at the top of the stack.

Thanks for your time!

Comments and changes to this ticket

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

People watching this ticket

Pages