Hangs when debugging with byebug

[gylaz]

When using byebug's debugger statement in a feature spec, and then attempting to find any element, the operation will hang. This is reproduced on several projects using capybara-webkit 1.3.1 and 1.4.1. In fact even trying to print page.body in the debugger repl hangs.

pry and using binding.pry for debugging works, but it's strange that byebug doesn't.

[travisp]

We were just noticing the same issue after updating byebug from 2.7.0 to 3.5.1 and pry-byebug from 1.3.3 to 2.0.0.

page.find works within the specs, but not when in a byebug debugging context, and only doesn't work with capybara-webkit. It works on earlier versions of byebug, so it's unclear to me if it's a byebug bug or a capybara-webkit bug.

[mhoran]

Fascinating. We use pry-byebug and I see the same behavior, whether I use binding.pry or byebug. A quick test shows the webkit_server process receives the expected commands, but something gets stuck afterwards:

[1] pry(#<RSpec::ExampleGroups::UsingTheNewInbox>)> find('a')
Received "FindCss(a)"
Started "FindCss(a)"
Finished "FindCss(a)" with response "Success(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54)"
Wrote response true "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54"

page.body seems to do the same thing -- the webkit_server process returns the expected content, but then hangs. This interaction only seems to affect byebug, as save_and_open_page works as expected.

[travisp]

I did some more debugging. It's challenging because there's no way I can figure out to step through the methods while in the byebug context. The code goes through this roughly:

Capybara::Session#html
Capybara::Session#driver
Capybara::Webkit::Driver#html
Capybara::Webkit::Browser#body
Capybara::Webkit::Browser#command
Capybara::Webkit::Browser#check
Capybara::Webkit::Connection#gets
Capybara::Webkit::Connection#read

In this last method, an IO::WaitReadable is raised and the method hangs on this code in the rescue block:

Thread.new { IO.select([@socket]) }.join

The code never moves past this

[mhoran]

Interesting. The Thread.new {}.join nonsense is there to work around a bug on JRuby. I'd prefer to get this fixed upstream, but if necessary we could work around it in capybara-webkit. However, it would seem other use of threads may cause issue, so that's not ideal.

It's also interesting that this behavior is exhibited with byebug itself, not just with pry. I don't know enough about the internals of either to speculate as to why that behavior changed between releases. Hopefully an upstream maintainer can help shed some light on the issue.

[deivid-rodriguez]

Hi guys, can you try to reproduce this using byebug's master?

Code using threads has never been really "debuggable", it has sporadically worked but was never really supported. Nevertheless, this has changed recently and it should be working fine against last master. If not, please open an issue in byebug's repo.

[mhoran]

Hey @deivid-rodriguez. A quick test shows this is still an issue with byebug master. However, I'm still working on extracting a simple example test case. I'll try to find a simple way to trigger this behavior.

[deivid-rodriguez]

@mhoran that sounds great!

[mhoran]

Issue opened: deivid-rodriguez/byebug#115.

[deivid-rodriguez]

@mhoran This can now be closed, right?

[deivid-rodriguez]

👍