Thread hangs

[andrewfader]

See deivid-rodriguez/byebug#115

I have an example repo here: https://github.com/andrewfader/minimal_byebug_hang

bash-3.2$ rspec
hello
Capybara: 2.4.4
capybara-webkit: 1.6.0
Qt: 5.4.2
WebKit: 538.1
QtWebKit: 5.4.2

From: /Users/pivotal/workspace/minimal_byebug_hang_repo/spec/capybara_test_spec.rb @ line 10 :

     5:   describe 'helo' do
     6:     it 'hi' do
     7:       puts "hello"
     8:       puts page.driver.version
     9:       binding.pry
 => 10:       puts 'we aint here'
    11:     end
    12:   end
    13: end

[1] pry(#<RSpec::ExampleGroups::ATest::Helo>)> page.driver.version

[deivid-rodriguez]

Thanks!

[dezmathio]

@deivid-rodriguez i saw on deivid-rodriguez/byebug#115 you said this was fixed... Is that in version 3.2.0 ? Which PR/commit did you fix it in? It's still hanging for me on my dev environment.

Edit: lol changed the keyword to be byebug instead of binding.pry and it works

[deivid-rodriguez]

Did I? When? I consider this as not fixed, that's why this issue is opened.

[williscool]

I think im running into this.

edit:

defintely am. If run the capybara test and just have a

puts page.body

or even

puts page.driver.cookies

I get the info on the console.

I can't use my beloved pry.. I'm so lost :(

fyi my whole gemfile

source 'https://rubygems.org'
gem 'sauce-cucumber'
gem 'capybara'
gem 'poltergeist'
gem 'rspec'
gem 'byebug' , '~> 8.1'
gem 'pry' , '~> 0.10'
gem 'pry-byebug' , '~> 3.3'

[deivid-rodriguez]

The solution to your problem is an easy one. Get rid of pry-byebug and use (your beloved) pry only! 😄

[williscool]

Doesn't work either way :(

Added byebug hoping it might help some how

Any other tips on how I might get around this?

Having to puts everything I want to debug out is no fun

[deivid-rodriguez]

You mean this happens using pry or byebug only as well? It shouldn't.

[williscool]

Using only binding.pry and using only byebug

*** Capybara::Poltergeist::TimeoutError Exception: Timed out waiting for response to {"name":"cookies","args":[]}. It's possible that this happened because something took a very long time (for example a page load was slow). If so, setting the Poltergeist :timeout option to a higher value will help (see the docs for details). If increasing the timeout does not help, this is probably a bug in Poltergeist - please report it to the issue tracker.

nil

even if I completely remove the other from the system (pry without byebug or byebug without pry)

also I'm using ruby 2.1.5

[deivid-rodriguez]

You can try two things:

• For binding.pry. have you also removed pry-byebug from your Gemfile? If you haven't, you're still using pry-byebug.
• For byebug, I'd need you to upgrade your ruby to either 2.1.7 or 2.2.3 and then apply this patch. Using rvm you can do, for example, rvm reinstall 2.1.7 --patch https://github.com/ruby/ruby/commit/2d4bc584eef5dcd11dbae4c92fe8b.patch or using ruby-install do ruby-install ruby 2.1.7 --p https://github.com/ruby/ruby/commit/2d4bc584eef5dcd11dbae4c92fe8b.patch. Let me know if that changes anything.

[williscool]

No dice on 2.1.7 with patch

get this error when running page.driver.cookies

Capybara::Poltergeist::TimeoutError: Timed out waiting for response to {"name":"cookies","args":[]}. It's possible that this happened because something took a very long time (for example a page load was slow). If so, setting the Poltergeist :timeout option to a higher value will help (see the docs for details). If increasing the timeout does not help, this is probably a bug in Poltergeist - please report it to the issue tracker.
from /home/pair/.rvm/gems/ruby-2.1.7/gems/poltergeist-1.7.0/lib/capybara/poltergeist/web_socket_server.rb:87:in `rescue in send'

both with pry and with byebug

[deivid-rodriguez]

Did you remove pry-byebug from your Gemfile and this fails in plain pry?

[williscool]

Wait. IT WORKS with byebug by itself!

but pry works neither way (with our without byebug)

and thanks for taking to help me debug. I really appreciate it even if we dont figure it all the way out

[williscool]

but its intermittent. sometimes it works sometimes it doesnt

[dezmathio]

I never really posted an update to our situation but we ended up just removing byebug completely. Even though it has amazing features, it wasn't compatible with our cucumber suite. I wonder if it would have worked just putting byebug under the development env in the Gemfile and pry in the test one. I'll have to test it out when I have more time.

[deivid-rodriguez]

@willscool So I ended up trying this again. Didn't want to but your information was very confusing. Nothing has changed:

• Works with byebug and pry alone.
• Hangs in pry-byebug.

@dezmathio Notice that this is pry-byebug's repository. If you have specific issues with byebug you can report them at byebug's repository (or obviously stop using it like you did).

[mikz]

So after fiddling with pry-byebug, pry and byebug alone. I must say this is problem of byebug.

When pry-byebug is removed from the gemfile, it is reproducible just with byebug alone.

Capybara-webkit hangs on:

/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-webkit-1.7.1/lib/capybara/webkit/connection.rb:58:in `call'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-webkit-1.7.1/lib/capybara/webkit/connection.rb:58:in `join'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-webkit-1.7.1/lib/capybara/webkit/connection.rb:58:in `rescue in read'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-webkit-1.7.1/lib/capybara/webkit/connection.rb:53:in `read'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-webkit-1.7.1/lib/capybara/webkit/connection.rb:46:in `gets'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-webkit-1.7.1/lib/capybara/webkit/browser.rb:299:in `check'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-webkit-1.7.1/lib/capybara/webkit/browser.rb:211:in `command'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-webkit-1.7.1/lib/capybara/webkit/node.rb:134:in `invoke'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-webkit-1.7.1/lib/capybara/webkit/node.rb:84:in `tag_name'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-2.5.0/lib/capybara/node/element.rb:240:in `block in tag_name'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-2.5.0/lib/capybara/node/base.rb:84:in `synchronize'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-2.5.0/lib/capybara/node/element.rb:240:in `tag_name'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-2.5.0/lib/capybara/node/element.rb:332:in `inspect'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/byebug-8.2.1/lib/byebug/helpers/eval.rb:112:in `safe_inspect'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/byebug-8.2.1/lib/byebug/processors/command_processor.rb:164:in `block in run_cmd'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/byebug-8.2.1/lib/byebug/processors/command_processor.rb:169:in `safely'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/byebug-8.2.1/lib/byebug/processors/command_processor.rb:160:in `run_cmd'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/byebug-8.2.1/lib/byebug/processors/command_processor.rb:149:in `repl'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/byebug-8.2.1/lib/byebug/processors/command_processor.rb:98:in `process_commands'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/byebug-8.2.1/lib/byebug/processors/command_processor.rb:78:in `at_return'
/Users/mikz/.rvm/gems/ruby-2.2.4/gems/byebug-8.2.1/lib/byebug/context.rb:128:in `at_return'

Here is the Thread.list:

[#<Thread:0x007f9e710bc400 run>, #<Process::Waiter:0x007f9e7a198348 sleep>, #<Thread:0x007f9e7a1abf60@/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-webkit-1.7.1/lib/capybara/webkit/connection.rb:104 sleep>, #<Thread:0x007f9e7a1eaad0@/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-2.5.0/lib/capybara/server.rb:69 sleep>, #<WEBrick::Utils::TimeoutHandler::Thread:0x007f9e7a282290@/Users/mikz/.rvm/rubies/ruby-2.2.4/lib/ruby/2.2.0/webrick/utils.rb:162 sleep>, #<Thread:0x007f9e7d733db8@/Users/mikz/.rvm/rubies/ruby-2.2.4/lib/ruby/2.2.0/webrick/server.rb:285 sleep>, #<Thread:0x007f9e7e2b05d8@/Users/mikz/.rvm/rubies/ruby-2.2.4/lib/ruby/2.2.0/webrick/server.rb:285 sleep>, #<Thread:0x007f9e7e2b0380@/Users/mikz/.rvm/rubies/ruby-2.2.4/lib/ruby/2.2.0/webrick/server.rb:285 sleep>, #<Thread:0x007f9e7e2b0128@/Users/mikz/.rvm/rubies/ruby-2.2.4/lib/ruby/2.2.0/webrick/server.rb:285 sleep>, #<Thread:0x007f9e76713768@/Users/mikz/.rvm/rubies/ruby-2.2.4/lib/ruby/2.2.0/webrick/server.rb:285 sleep>, #<Thread:0x007f9e7d0db4c0@/Users/mikz/.rvm/gems/ruby-2.2.4/gems/capybara-webkit-1.7.1/lib/capybara/webkit/connection.rb:58 sleep>]

It makes sense. Capybara starts a thread to wait for a socket, but byebug stops everything, so the thread can never complete.

[Ch4s3]

I'm having the same issue on 3.3.0 in Capybara-webkit.

[zacharyjt]

I am also seeing the same issue with 3.3.0 in capybara-webkit 1.8.0

[ben2d2]

Also seeing this issue with 3.3.0 in capybara-webkit 1.7.1

[deivid-rodriguez]

Linking this the actual issue which seems to be inside byebug. deivid-rodriguez/byebug#193

Also, let's use reactions for dummy +1 comments!

[benlieb]

same issue, sad :(

any progress, workarounds? I'm just switching to gem 'pry' when I need to debug feature specs, which is basically all of the time

[deivid-rodriguez]

Nope. Feel free to help.

[j3pic]

It's still happening to me. I have an even more minimal test case:

#!/usr/bin/env ruby

require 'pry-byebug'

def test_thread
  t = Thread.start do
    $test_thread=:test
  end
  sleep 1
  if $test_thread != :test
    puts "test_thread failed!"
    raise "Test thread failed to set $test_thread!"
  else
    puts "Test thread value: #{$test_thread}"
  end
  t.terminate
  $test_thread=nil
end


binding.pry
nil

Call test_thread from the Pry prompt and it'll detect that the thread t has hung. It probably has something to do with the way Byebug stops all threads for debugging.

[deivid-rodriguez]

Fixed via #142!