Giter VIP home page Giter VIP logo

Comments (24)

deivid-rodriguez avatar deivid-rodriguez commented on May 31, 2024 7

Fixed via #142!

from pry-byebug.

benlieb avatar benlieb commented on May 31, 2024 3

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

from pry-byebug.

deivid-rodriguez avatar deivid-rodriguez commented on May 31, 2024 1

Nope. Feel free to help.

from pry-byebug.

deivid-rodriguez avatar deivid-rodriguez commented on May 31, 2024

Thanks!

from pry-byebug.

dezmathio avatar dezmathio commented on May 31, 2024

@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 :trollface:

from pry-byebug.

deivid-rodriguez avatar deivid-rodriguez commented on May 31, 2024

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

from pry-byebug.

williscool avatar williscool commented on May 31, 2024

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'

from pry-byebug.

deivid-rodriguez avatar deivid-rodriguez commented on May 31, 2024

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

from pry-byebug.

williscool avatar williscool commented on May 31, 2024

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

from pry-byebug.

deivid-rodriguez avatar deivid-rodriguez commented on May 31, 2024

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

from pry-byebug.

williscool avatar williscool commented on May 31, 2024

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

from pry-byebug.

deivid-rodriguez avatar deivid-rodriguez commented on May 31, 2024

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.

from pry-byebug.

williscool avatar williscool commented on May 31, 2024

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

from pry-byebug.

deivid-rodriguez avatar deivid-rodriguez commented on May 31, 2024

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

from pry-byebug.

williscool avatar williscool commented on May 31, 2024

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

from pry-byebug.

williscool avatar williscool commented on May 31, 2024

but its intermittent. sometimes it works sometimes it doesnt

from pry-byebug.

dezmathio avatar dezmathio commented on May 31, 2024

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.

from pry-byebug.

deivid-rodriguez avatar deivid-rodriguez commented on May 31, 2024

@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).

from pry-byebug.

mikz avatar mikz commented on May 31, 2024

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.

from pry-byebug.

Ch4s3 avatar Ch4s3 commented on May 31, 2024

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

from pry-byebug.

zacharyjt avatar zacharyjt commented on May 31, 2024

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

from pry-byebug.

ben2d2 avatar ben2d2 commented on May 31, 2024

Also seeing this issue with 3.3.0 in capybara-webkit 1.7.1

from pry-byebug.

deivid-rodriguez avatar deivid-rodriguez commented on May 31, 2024

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

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

from pry-byebug.

j3pic avatar j3pic commented on May 31, 2024

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.

from pry-byebug.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.