Comments (24)
Fixed via #142!
from pry-byebug.
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.
Nope. Feel free to help.
from pry-byebug.
Thanks!
from pry-byebug.
@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
from pry-byebug.
Did I? When? I consider this as not fixed, that's why this issue is opened.
from pry-byebug.
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.
The solution to your problem is an easy one. Get rid of pry-byebug
and use (your beloved) pry
only! 😄
from pry-byebug.
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.
You mean this happens using pry
or byebug
only as well? It shouldn't.
from pry-byebug.
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.
You can try two things:
- For
binding.pry
. have you also removedpry-byebug
from yourGemfile
? If you haven't, you're still usingpry-byebug
. - For
byebug
, I'd need you to upgrade your ruby to either2.1.7
or2.2.3
and then apply this patch. Usingrvm
you can do, for example,rvm reinstall 2.1.7 --patch https://github.com/ruby/ruby/commit/2d4bc584eef5dcd11dbae4c92fe8b.patch
or usingruby-install
doruby-install ruby 2.1.7 --p https://github.com/ruby/ruby/commit/2d4bc584eef5dcd11dbae4c92fe8b.patch
. Let me know if that changes anything.
from pry-byebug.
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.
Did you remove pry-byebug
from your Gemfile
and this fails in plain pry
?
from pry-byebug.
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.
but its intermittent. sometimes it works sometimes it doesnt
from pry-byebug.
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.
@willscool So I ended up trying this again. Didn't want to but your information was very confusing. Nothing has changed:
- Works with
byebug
andpry
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.
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.
I'm having the same issue on 3.3.0 in Capybara-webkit.
from pry-byebug.
I am also seeing the same issue with 3.3.0 in capybara-webkit 1.8.0
from pry-byebug.
Also seeing this issue with 3.3.0 in capybara-webkit 1.7.1
from pry-byebug.
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.
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)
- It's possible to start a REPL session passing a command? HOT 1
- Loading pry-byebug on Archlinux fails with "cannot load such file -- irb" HOT 1
- Newest version of Pry breaks pry-byebug HOT 15
- Pry Byebug specifies an older version of Pry HOT 1
- Deprecation warnings in Ruby 2.7 HOT 2
- Pry "next" alias does not work
- Any plans for a new release? HOT 4
- less: unrecognized option: X HOT 1
- PR proposition : Deprecated - Pry.config.control_d_handler HOT 6
- Repeated newlines in multi-line strings are ignored
- NameError: undefined local variable or method `text' for #<PryByebug::BreakCommand HOT 2
- New release? HOT 2
- Deprecation warnings Pry v 0.14.1 on Ruby v 3.1.1 HOT 1
- Relax restriction for byebug version HOT 5
- The version 3.10.0 breaks rails console HOT 8
- Build failure with ruby-pry-byebug version 3.9.0-1
- Run error using Ruby 3.2 HOT 1
- Deprecation on Ruby 3.2.2
- Compatibility Inquiry: pry-byebug 3.10.1 with Ruby 3.3.0
- Question: Is there a recommended way of requiring the gem for test but not CI?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pry-byebug.