Find seems to block on linux?

[iainbeeston]

I have found a strange bug. On my macbook, when I run this in a spec:

wait_until { page.find('.header .tab.selected').text.include?('Set up sharing') }

with debug enabled I can see this in the logs:

{"name"=>"find", "args"=>[".//*[contains(concat(' ', @class, ' '), ' header ')]//*[contains(concat(' ', @class, ' '), ' tab ') and contains(concat(' ', @class, ' '), ' selected ')]"]}
{"response"=>{"page_id"=>1, "ids"=>[17]}}
{"name"=>"visible", "args"=>[1, 17]}
{"response"=>true}
{"name"=>"text", "args"=>[1, 17]}
{"response"=>"1. Create your account\n                "}

{"name"=>"find", "args"=>[".//*[contains(concat(' ', @class, ' '), ' header ')]//*[contains(concat(' ', @class, ' '), ' tab ') and contains(concat(' ', @class, ' '), ' selected ')]"]}
{"response"=>{"page_id"=>1, "ids"=>[18]}}
{"name"=>"visible", "args"=>[1, 18]}
{"response"=>true}
{"name"=>"text", "args"=>[1, 18]}
{"response"=>"1. Create your account\n                "}

{"name"=>"find", "args"=>[".//*[contains(concat(' ', @class, ' '), ' header ')]//*[contains(concat(' ', @class, ' '), ' tab ') and contains(concat(' ', @class, ' '), ' selected ')]"]}
{"response"=>{"page_id"=>1, "ids"=>[19]}}
{"name"=>"visible", "args"=>[1, 19]}
{"response"=>true}
{"name"=>"text", "args"=>[1, 19]}
{"response"=>"2. Set up sharing"}

To summarise, it checks repeatedly until the statement is true or it times out. The markup it's looking for is placed on the page dynamically, and this is exactly the behaviour I want.

But when I run it on our build server (which runs ubuntu) I only get this:

{"name"=>"find", "args"=>[".//*[contains(concat(' ', @class, ' '), ' header ')]//*[contains(concat(' ', @class, ' '), ' tab ') and contains(concat(' ', @class, ' '), ' selected ')]"]}

and no further commands run for several seconds (I have my capybara wait time set to 5 seconds) before I get a timeout error:

Timed out waiting for response to {"name":"find","args":[".//*[contains(concat(' ', @class, ' '), ' header ')]//*[contains(concat(' ', @class, ' '), ' tab ') and contains(concat(' ', @class, ' '), ' selected ')]"]} (Capybara::Poltergeist::TimeoutError)
(eval):2:in `find'

So it's running the find, which is blocking and then the timeout is kicking in.

I'm at a loss as to what's causing this. I suspect it might be phantomjs (I've tried reinstalling it from source vs the prebuilt package) or capybara but it's hard to tell which part of the stack is failing, and why it might be happening on one platform rather than another.

If I can get any help tracking down where this is blocking then that would be great!

[jonleighton]

This looks like PhantomJS is failing to run properly for some reason. But Poltergeist is supposed to detect this and provide a useful error message.

Does phantomjs --version work? When your test is running, can you see a phantomjs process running?

[iainbeeston]

Now we're onto something. I checked whether phantomjs is running (as you suggested) and I can see that the phantomjs process does start up when the test is run, but then dies silently around the time that wait_until is called. Poltergeist doesn't seem to notice this and then fails after a few seconds due to a timeout (ie. "Timed out waiting for response"). Unfortunately I can't find where phantomjs is logging to (certainly not to any of the usual places in my app or in the system logs), so I can't see exactly why it's dying. Is there some way I can get at the logs from the phantomjs child process?

FYI when I run phantomjs --version it does work, and if I replace the wait_until statements with a sleep then phantomjs works fine and the tests all run to completion (although then they fail occasionally if the sleep isn't long enough - so this isn't a reliable solution).

[jonleighton]

That sounds like PhantomJS is segfaulting. I need to add a feature that allows people to easily get a stack trace for these situations. (See issue #44.) Sorry :(

[iainbeeston]

Ah I see. Would it be hard for someone new to phantomjs to make a pull request for that? (Failing that I'll have to switch back to capybara-webkit :-( )

[jonleighton]

Even with that feature, the stack trace will only get us part way to a resolution, because it will need a fix inside PhantomJS to fully solve. So I think your best bet is to use something else for the time being. Sorry :/

What OS are you using btw?

[iainbeeston]

I'm using Ubuntu 10.10 x86_64 (kernel 2.6.39)

[jonleighton]

Can you try something for me? Run "ulimit -c unlimited" in the shell where you run the test, before running the test. This means that a core file should get dumped when phantomjs crashes, which you can send to me and I can (hopefully) work out what's going on. Thanks.

[iainbeeston]

Ok I've tried but I'm getting no core dumps (in the working directory at
least). Sorry!

[jonleighton]

Hmm, that's odd.

I have been thinking about the problem of crashes more generally, and I think core dumps are going to be an impractical way to deal with it. So I have been working on integrating a crash reporter into phantomjs itself.

I've got it working on Linux only at the moment, but that should be okay for you. If you want to try it out, you will need to build my branch (usual way - by running ./build.sh). PhantomJS should then print a message saying "I've crashed, here's a crash dump file".

If you don't have time for this at the moment, just wait a few weeks for the next PhantomJS release which should include this crash reporter.

[jonleighton]

One more thing I just thought of - I am assuming that PhantomJS crashed but that's not necessarily true I guess. We should check this - if it's not crashing that'd explain why you didn't get a core dump. So try running your test that hangs and just use ps in another terminal to check whether the phantomjs process is still around.

[iainbeeston]

Awesome - thanks for the help Jon. I'll give it a try in the next day or
two.

Iain

[jonleighton]

@iainbeeston any update on this? have you tried phantomjs 1.6? that should generate a crash dump if it crashes.

[iainbeeston]

@jonleighton Ack... Sorry, that was the longest day or two in history (right after I posted that we decided to move to selenium for strategic reasons... eg. for popups and stability).

I've tried the same test as above, but with poltergeist 0.7 and phantomjs 1.6.1 and now it works perfectly, without crashing. So I'll close this issue. Unfortunately I've still no idea what the original cause was.