Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Capybara-webkit stops / hangs unexpectedly and inconsistently #399

Closed
mattheworiordan opened this Issue · 60 comments
@mattheworiordan

Firstly, I appreciate how hard it is to debug this issue, or even figure out if Capybara-webkit is indeed at fault, but I believe Capybara-Webkit, QT Webkit, and or Capybara are causing the problem, with the former two being the more likely. So I appreciate any help if you can help.

I am on OS X 10.8.1 with the latest version of all gems, QT webkit 4.8.3 and Ruby 1.9.3 available. I'll post the info further down for your reference.

I have found that recently after upgrading my OS and installing the latest QT & Capybara-webkit Gem, when running a few small Cucumber tests using rake cucumber:wip everything tends to work fine. However, when I run the full suite I find the tests just hang for some reason, and never fix themselves. I have seen this in my CI environment (Mac as well, but OS OX 10.7, and latest versions of everything else) as well. However, if I set Capybara.javascript_driver = :selenium instead of Capybara.javascript_driver = :webkit then I don't experience this behaviour

I can reproduce this error easily by running rake cucumber, the first 34 scenarios across 5 feature files run OK, and then oddly when I hit the 6th feature file (one of many more), it hangs on the first scenario before what seems like Capybara-Webkit has even been invoked. However, clearly it is because when Selenium is used this issue does not exist.

Here is the output from the test on that scenario showing, and importantly it does not seem like the @javascript interpretor has yet been invoked (I use capybara-webkit) as it got stuck on the Background portion:

Feature: Backlog Other Functionality
  In order to manage a backlog
  A visitor
  Should be able to rely on some necessary functionality

  Background:                                                                                      # features/backlog_other.feature:6
    Given the database has the necessary lookup tables                                             # features/step_definitions/shared_steps.rb:1
    And a user named "John" is registered                                                          # features/step_definitions/authentication_steps.rb:1

The @javascript declaration in fact comes later in the scenario declaration, not in the background section, so to be honest I'm not sure if Capybara detects that in advance and switches to the :javascript driver, or if it only switches when the Scenario starts that is tagged with @javascript.

Anyway, clearly it is hanging on the next step in the Background which is And I am signed in as "John"
The code for this step is as follows:

step %{I am on the home page}
step %{I follow "Log in"}
step %{I fill in "Email" with "#{user_name.gsub(/ /,'')}@acme.com"}
step %{I fill in "Password" with "password"}
step %{I press "Log in"}
step %{I should see the notice "Signed in successfully."}

Now I could include all the code for this step if you want, but it's all pretty bog standard Capybara code. For example, here are two of the steps:

Given /^(?:|I )am on (.+)$/ do |page_name|
  visit path_to(page_name)
end

When /^(?:|I )follow "([^"]*)"(?: within "([^"]*)")?$/ do |link, selector|
  with_scope(selector_to(selector)) do
    click_link(link)
  end
end

So why it should hang on this step confuses me. There is certainly nothing in those steps that warrants any odd behaviour, and if I run that test individually it works just fine.

I have included a debug log using Capybara.javascript_driver = :webkit_debug for:

  • A full rake cucumber which fails every time and hangs - please see capybara-webkit.log
  • rake cucumber:wip which runs the same scenario tagged with @wip that fails when run as part of rake cucumber - please see capybara-webkit-wip.log

So why it works on its own, and not with others is beyond me.

Looking at the log it seems that it gets stuck at the last line http://127.0.0.1:64775/

Oddly however, whilst it is hung, I run the following command and it responds just fine:
$ curl http://127.0.0.1:64775/ -I
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Ua-Compatible: IE=Edge,chrome=1
Etag: "5ea29e44392cd954eb3c57e2464ad3b0"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 408a00e6fcecefc59c7837b6f9215d79
X-Runtime: 0.035834
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
Date: Wed, 17 Oct 2012 17:04:18 GMT
Content-Length: 0
Connection: Keep-Alive
Set-Cookie: _easybacklog_session=BAh7B0kiD3Nlc3Npb25faWQGOgZFRkkiJTdlMzBhZTFkODEyZDRjYmQ0ZDMyNDAyNTBmZjk1OWJkBjsAVEkiDWxhc3RfdXJsBjsARkkiBi8GOwBG--ac40a5343fc67f1e0d8563994c10a068839ef97e; path=/; HttpOnly

Here is some info on my environment:

OS X Version: 10.8.1
Ruby: ruby-1.9.3-p194 using RVM
XCode version: 4.5.1

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

$ bundle list
Gems included by the bundle:

  • Ascii85 (1.0.2)
  • ZenTest (4.8.2)
  • actionmailer (3.2.8)
  • actionpack (3.2.8)
  • activemodel (3.2.8)
  • activerecord (3.2.8)
  • activeresource (3.2.8)
  • activesupport (3.2.8)
  • acts_as_list (0.1.8)
  • addressable (2.3.2)
  • arel (3.0.2)
  • autotest (4.4.6)
  • autotest-growl (0.2.16)
  • autotest-rails (4.1.2)
  • awesome_print (1.1.0)
  • bcrypt-ruby (3.0.1)
  • builder (3.0.3)
  • bundler (1.2.0)
  • capybara (1.1.2)
  • capybara-screenshot (0.2.2)
  • capybara-webkit (0.12.1)
  • childprocess (0.3.5)
  • chunky_png (1.2.6)
  • coderay (1.0.8)
  • columnize (0.3.6)
  • compass (0.12.2)
  • compass-960-plugin (0.10.4)
  • compass-rails (1.0.3)
  • cucumber (1.2.1)
  • cucumber-rails (1.3.0)
  • database_cleaner (0.9.1)
  • debugger (1.2.0)
  • debugger-linecache (1.1.2)
  • debugger-ruby_core_source (1.1.3)
  • deep_merge (1.0.0)
  • devise (2.1.2)
  • devise-encryptable (0.1.1)
  • diff-lcs (1.1.3)
  • ejs (1.1.1)
  • email_spec (1.2.1)
  • erubis (2.7.0)
  • exceptional (2.0.32)
  • excon (0.16.4)
  • execjs (1.4.0)
  • factory_girl (4.1.0)
  • factory_girl_rails (4.1.0)
  • ffi (1.1.5)
  • foreman (0.60.0)
  • fssm (0.2.9)
  • gherkin (2.11.4)
  • growl (1.0.3)
  • haml (3.1.7)
  • hashery (2.0.1)
  • heroku (2.32.11)
  • heroku-api (0.3.5)
  • heroku_san (3.0.4)
  • hike (1.2.1)
  • hpricot (0.8.6)
  • httparty (0.9.0)
  • i18n (0.6.1)
  • journey (1.0.4)
  • jquery-rails (2.1.3)
  • jslint_on_rails (1.1.1)
  • json (1.7.5)
  • kgio (2.7.4)
  • launchy (2.1.2)
  • libwebsocket (0.1.5)
  • mail (2.4.4)
  • method_source (0.8)
  • mime-types (1.19)
  • multi_json (1.3.6)
  • multi_xml (0.5.1)
  • netrc (0.7.7)
  • newrelic_rpm (3.4.2)
  • nokogiri (1.5.5)
  • orm_adapter (0.4.0)
  • pdf-reader (1.2.0)
  • pg (0.14.1)
  • polyglot (0.3.3)
  • prawn (0.12.0)
  • pry (0.9.10)
  • pry-rails (0.0.4 6dd39e3)
  • quiet_assets (1.0.1)
  • rack (1.4.1)
  • rack-cache (1.2)
  • rack-force_domain (0.2.0 ff16ac9)
  • rack-ssl (1.3.2)
  • rack-test (0.6.2)
  • rails (3.2.8)
  • railties (3.2.8)
  • raindrops (0.10.0)
  • rake (0.9.2.2)
  • rdoc (3.12)
  • recursive-open-struct (0.2.2 8178fa5)
  • redis (2.2.2)
  • redis-namespace (1.0.3)
  • rest-client (1.6.7)
  • rspec (2.11.0)
  • rspec-core (2.11.1)
  • rspec-expectations (2.11.3)
  • rspec-mocks (2.11.3)
  • rspec-rails (2.11.0)
  • ruby-rc4 (0.1.5)
  • ruby_parser (2.3.1)
  • rubyzip (0.9.9)
  • sass (3.2.1)
  • sass-rails (3.2.5)
  • selenium-webdriver (2.25.0)
  • sequel (3.20.0)
  • sexp_processor (3.2.0)
  • shortly (0.3.3)
  • shoulda-matchers (1.4.0)
  • sinatra (1.0)
  • slop (3.3.3)
  • sprockets (2.1.3)
  • taps (0.3.24)
  • thor (0.16.0)
  • tilt (1.3.3)
  • timecop (0.5.2)
  • treetop (1.4.11)
  • ttfunk (1.0.3)
  • turbo-sprockets-rails3 (0.1.15)
  • tzinfo (0.3.33)
  • uglifier (1.3.0)
  • unicorn (4.3.1)
  • vanity (1.8.0 dda319f)
  • warden (1.2.1)
  • watchr (0.7)
  • webrat (0.7.3)
  • will_paginate (3.0.3)
  • xml-object (0.9.93)
  • xpath (0.1.4)

$ brew info qt

qt: stable 4.8.3 (bottled), HEAD
http://qt.nokia.com/
/usr/local/Cellar/qt/4.8.2 (2753 files, 195M)
/usr/local/Cellar/qt/4.8.3 (2779 files, 194M) *
https://github.com/mxcl/homebrew/commits/master/Library/Formula/qt.rb
==> Options
--developer
  Compile and link Qt with developer options
--with-qt3support
  Enable deprecated Qt3Support module
--with-debug-and-release
  Compile Qt in debug and release mode
--with-qtdbus
  Enable QtDBus module
--universal
  Build a universal binary
--with-mysql
  Enable MySQL plugin
--with-demos-examples
  Enable Qt demos and examples
==> Caveats
We agreed to the Qt opensource license for you.
If this is unacceptable you should uninstall.
@mattheworiordan

BTW. I just tried uninstalling and installing Qt and installling with version 4.8.2 and I had the same issue.

@mhoran
Collaborator

Please check out the latest master and see if it resolves your issues. We just pushed a number of fixes for Qt 4.8.

@mattheworiordan

Sorry, unfortunately it doesn't work :(

It gets stuck on this line in my Cucumber steps now, which is different admittedly:

@javascript
Scenario: Duplicate a backlog # features/backlog.feature:33
When I follow "Create a new backlog" # features/step_definitions/web_steps.rb:27
And I fill in "Name the backlog" with "Project X" # features/step_definitions/web_steps.rb:33
And I press "Create new backlog" # features/step_definitions/web_steps_extra.rb:1

@xn
xn commented

Looks like a co worker and myself are getting the same issue.

@jferris
Admin

@mattheworiordan can you paste a log from the webkit_debug driver using master? The debugging output is much better for this kind of thing now.

@mattheworiordan
@xn
xn commented

Where is this log? just the rails test.log?

@mattheworiordan

@jferris, here is the log when running cucumber
http://speedy.sh/M3zSK/cucumber.log

@jferris
Admin

@mattheworiordan do you know what's going on in your code when that happens? It seems like maybe it's starting some requests and then canceling them somehow, and capybara-webkit doesn't realized that the request has been canceled.

@mattheworiordan

Here are the 4 steps of my scenario, it seems the final one never fires, or perhaps it hangs on this step:

When I follow "Create a new backlog"
  And I fill in "Name the backlog" with "Project X"
  And I press "Create new backlog"
Then I should see the notice "Backlog was successfully created."

And I press "Create new backlog" simply executes the following code:

When /^(?:|I )press "([^"]*)"(?: within (?:|the )"([^"]*)")?$/ do |button, selector|
  selector_css = selector_to(selector)
  sleep 0.2 if selector_css.present? && !page.has_css?(selector_css) # https://github.com/thoughtbot/capybara-webkit/issues/36
  with_scope(selector_css) do
    click_button(selector_to(button, :dont_translate_to_css=>true))
  end
end

Then I should see the notice "Backlog was successfully created." executes the following code:

Then /^(?:|I )should (|not )see the (notice) "([^"]+)"$/ do |negation, notice_alert, message|
  selector = "#alert-space .#{notice_alert}"
  unless negation.strip == "not" && page.has_no_selector?(selector) # if notice not shown at all allow this to pass if in the negative
    within(selector) do |content|
      if negation.strip == "not"
        page.should_not have_content(message)
      else
        page.should have_content(message)
      end
    end
  end
end

To be honest, I can't see anything particularly unusual in any of this?

Not sure what else I can provide. I appreciate you looking into this, it's a really odd problem.

@jferris
Admin

Can you use $stdout.puts statements to track down exactly which line it's halting on? I don't see anything odd in there, either, but it would be good to know exactly where it's stopping. If you can paste some of the production code that the problematic step is exercising, that would also be useful. Are iframes or windows involved?

@mattheworiordan

Ok, I added the debug messages and was able to isolate it down to a single line that hangs.

Here is the complete log http://www.speedyshare.com/5UKwq/cucumber.log

In my logs, after using $stdout.puts I get the following debug information:

notice check  notice Backlog was successfully created.
notice check notice_alert notice
notice check selector #alert-space .notice
notice check passed selector check

After that it goes into webkit_debug output and does not seem to ever return back to my Cucumber steps.

The code matching the above notices is as follows:

Then /^(?:|I )should (|not )see the (notice|alert|error|warning) "([^"]+)"$/ do |negation, notice_alert, message|
  $stdout.puts "notice check #{negation} #{notice_alert} #{message}"
  notice_alert = 'error' if notice_alert == 'alert' # errors and alerts are stored in the same .error class
  $stdout.puts "notice check notice_alert #{notice_alert}"
  selector = "#alert-space .#{notice_alert}"
  $stdout.puts "notice check selector #{selector}"
  unless negation.strip == "not" && page.has_no_selector?(selector) # if notice not shown at all allow this to pass if in the negative
    $stdout.puts "notice check passed selector check"
    within(selector) do |content|
      $stdout.puts "notice check within #{selector}"
      if negation.strip == "not"
        page.should_not have_content(message)
      else
        page.should have_content(message)
      end
      $stdout.puts "notice check finished"
    end
  end
end

So it looks like it's hanging on the line with the value:
within('#alert-space .notice') do |content|

I then thought it might be useful to take a screen shot beforehand as it may help with debugging, and that is when things became odd. I added a new line to the Cucumber steps Then screenshot the page which simply executes screenshot_and_save_page. However, when I ran cucumber the second time round hoping to get a screenshot, I did not see the debug messages notice check*, meaning it hung before it even got to that so probably on the screen shot line. Does this some how mean that Capybara-Webkit is sort of getting stuck on whatever requests comes after the previous Create a new backlog action.

I just don't know where to go from here. Happy to do whatever debugging you want though.

@mattheworiordan

BTW. I wondered if capybara-screenshot was interfering, so I reran the tests without that Gem installed and the same thing happened. I also added a debug line above page.save_page and that gets run, but as soon as page.save_page executes it seems capybara-webkit starts downloading the page..

Received "Body" 
"TimeoutCommand" waiting for load to finish 
Started request to "http://127.0.0.1:62222/accounts/1/backlogs/2" 
Received 302 from "http://127.0.0.1:62222/accounts/1/backlogs" 
1 requests remaining 
....
4 requests remaining 
Page finished with true 

And just hangs there.

@mattheworiordan

@jferris, oddly I have never actually waited more than around a few minutes once Capybara-Webkit hangs, and always killed the process. This time however I left it running by mistake and when I came back it was running more tests.

Here is the log http://speedy.sh/QGH55/cucumber.log

Look at line 17441 and you will see we get an error: No response received from the server. (Capybara::Webkit::NoResponseError)

Also, if you look at line 17482 you will see that every test afterwards now fails with:
Broken pipe (Errno::EPIPE)

Maybe that will help diagnose the issue?

@jferris
Admin

That pair of errors means that the server crashed after a while. Can you try sending it this command in a before block?

page.driver.browser.timeout = 10
@mattheworiordan
@mattheworiordan

Ok, so the tests complete, but I have loads of failing tests because 10s is not quite enough for some of the more in-depth steps. I am not really sure if this is fixing the issue, or just working around the hanging server issue though. I will re-run with a more generous 20s allowance and see if the original test fails or not

@mattheworiordan

Ok, unfortunately even with 20s delay, it runs into problems.

I keep getting errors such as:

  Received "Reset" 
  Started "Reset" 
  Finished "Reset" with response "Success()" 
  Wrote response true "" 
        Connection refused - connect(2) (Errno::ECONNREFUSED)
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:762:in `initialize'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:762:in `open'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:762:in `block in connect'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/timeout.rb:54:in `timeout'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/timeout.rb:99:in `timeout'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:762:in `connect'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:755:in `do_start'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:744:in `start'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:1284:in `request'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/http/default.rb:83:in `response_for'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/http/default.rb:39:in `request'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/http/common.rb:40:in `call'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/bridge.rb:598:in `raw_execute'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/bridge.rb:576:in `execute'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/bridge.rb:350:in `deleteAllCookies'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/common/options.rb:67:in `delete_all_cookies'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/selenium/driver.rb:81:in `reset!'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/session.rb:70:in `reset!'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/dsl.rb:87:in `block in reset_sessions!'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/dsl.rb:87:in `each'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/dsl.rb:87:in `reset_sessions!'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/cucumber.rb:10:in `After'
@jferris
Admin

That backtrace has selenium-webdriver in it and not capybara-webkit. Are you using selenium for some scenarios?

@mattheworiordan
@jferris
Admin

Yeah, I think that log could be useful. If it's hanging sometimes during scenarios unrelated to capybara-webkit, there's another, unrelated issue at play here. There could also be a bug with capybara-webkit that you're running into, but you're definitely running into a different bug.

@mattheworiordan

No, sorry, I think you've misunderstood.

I ONLY get the issue with capybara-webkit.

However, when I run the complete suite of tests there are some non-capybara-webkit stories in there, so I can see why one might see that the issue is not necessarily capybara-webkit.
However, if I run cucumber tags=@javascript cucumber then filters out all other stories and only runs the capybara-webkit stories and still hangs, meaning it's definitely a capybara-webkit related issue. If I change the driver to selenium and run all the tests with Selenium instead, it works fine.

@jnimety

I'm running into this as well in a selenium free rspec test suite using 0.13.0. I've set page.driver.browser.timeout=40 and started using webkit_debug to get a backtrace but no additional info gets logged (other than webkit_debug logging "Timeout(40)"). Am I missing additional configs to get the bt?

@jferris
Admin

@jnimety If you're setting the timeout to 40, it should timeout after 40 seconds. I don't know why it isn't. Can you open a separate issue and paste the log, what your test code looks like, and what your production code looks like where it hangs?

I got access to an application that deadlocks during the test suite, so I'm going to try and figure out what the race condition is.

@jnimety

the timeout is working, I'm just not getting a backtrace like @mattheworiordan. If you have a failing scenario I'll stop debugging, I was just trying to get you more info. Thanks.

@nsocheleau

I'm experiencing it as well, I think.

It gets stuck in my login step with the following ouput from webkit_debug:

Received "Node.click" 
Started "Node.click" 
Finished "Node.click" with response "Success()" 
Wrote response true "" 
Load started 
Started request to "http://127.0.0.1:42197/users/sign_in" 
Received "Find" 
"TimeoutCommand" waiting for load to finish 
Started request to "http://127.0.0.1:42197/" 
Received 200 from "http://127.0.0.1:42197/" 
1 requests remaining 
Page finished with true

what the step does:
1. click the login button
2. HTTP POST with the credentials to /users/sign_in
3. response is a 302 redirecting to /

But before that, I had a scenario with that same login step that passed with the following output from webkit_debug:

Received "Node.click" 
Started "Node.click" 
Finished "Node.click" with response "Success()" 
Wrote response true "" 
Load started 
Started request to "http://127.0.0.1:42197/users/sign_in" 
Received "Find" 
"TimeoutCommand" waiting for load to finish 
Started request to "http://127.0.0.1:42197/" 
Received 302 from "http://127.0.0.1:42197/users/sign_in" 
1 requests remaining 
Received 200 from "http://127.0.0.1:42197/" 
0 requests remaining 
Page finished with true 
Load finished 

When it gets stuck, it looks like the 302 response is not notified back to the client from the webkit server or something like that.

Hope this helps.
Nicolas

@jferris
Admin

@nsocheleau can you show some of the production code that this is testing? I tried reproducing a similar scenario, and my output is different:

Received "Node.click" 
Started "Node.click" 
Finished "Node.click" with response "Success()" 
Wrote response true "" 
Load started 
Started request to "http://127.0.0.1:53338/users/sign_in" 
Received 302 from "http://127.0.0.1:53338/users/sign_in" 
0 requests remaining 
Started request to "http://127.0.0.1:53338/" 
Received "Find" 
"TimeoutCommand" waiting for load to finish 
Received 200 from "http://127.0.0.1:53338/" 
0 requests remaining 
Page finished with true 
Load finished 

Note that the 302 always finishes before starting the redirected target, and I never have "1 requests remaining" in the log.

Also, what platform (version of Qt, Linux/Windows/whatever) are you on?

@nsocheleau

Hello,

I've reproduced that issue on linux with Qt 4.8.3 and mac with Qt 4.8.0.

I cannot reproduce it consistently though. It happens when I run the full suite of cucumber tests. If I run again the scenario that just hang, it will pass.

Here are the cucumber steps just before it stops for the log above:

  visit(new_user_session_path)
  fill_in("Username", :with => email)
  fill_in("Password", :with => password)
  click_button("Sign in")
  page.should have_content("Signed in successfully.")

Here are the list of gems used in my project (the login above is handled by devise):

  • Ascii85 (1.0.1)
  • actionmailer (3.1.3)
  • actionpack (3.1.3)
  • activemodel (3.1.3)
  • activerecord (3.1.3)
  • activerecord-sqlserver-adapter (3.1.7)
  • activeresource (3.1.3)
  • activesupport (3.1.3)
  • acts_as_api (0.4)
  • acts_as_list (0.1.6 ba0962d)
  • addressable (2.2.8)
  • archive-tar-minitar (0.5.2)
  • arel (2.2.3)
  • backup (3.0.24)
  • bcrypt-ruby (3.0.1)
  • builder (3.0.0)
  • bullet (4.2.0)
  • bundler (1.2.1)
  • cancan (1.6.7)
  • capistrano (2.12.0)
  • capistrano-ext (1.2.1)
  • capybara (1.1.2)
  • capybara-webkit (0.12.1)
  • carrierwave (0.5.8)
  • childprocess (0.3.6)
  • chronic (0.6.7)
  • coffee-rails (3.1.1)
  • coffee-script (2.2.0)
  • coffee-script-source (1.3.1)
  • columnize (0.3.6)
  • cucumber (1.1.9)
  • cucumber-rails (1.3.0)
  • daemon_controller (1.0.0)
  • daemons (1.1.8)
  • database_cleaner (0.7.2)
  • devise (2.0.4)
  • devise_invitable (1.0.1)
  • diff-lcs (1.1.3)
  • dotiw (1.1.1)
  • email_spec (1.2.1)
  • erubis (2.7.0)
  • eventmachine (0.12.10)
  • excel_rails (0.3.0)
  • exception_notification (2.6.1)
  • excon (0.9.6)
  • execjs (1.3.1)
  • fabrication (1.3.2)
  • faker (1.0.1)
  • fastthread (1.0.7)
  • fattr (2.2.1)
  • ffi (1.1.5)
  • fog (1.1.2)
  • formatador (0.2.3)
  • formtastic (2.2.0)
  • gherkin (2.9.3)
  • highline (1.6.11)
  • hike (1.2.1)
  • hodel_3000_compliant_logger (0.1.0)
  • i18n (0.6.0)
  • jquery-rails (1.0.19)
  • json (1.7.3)
  • kaminari (0.13.0)
  • launchy (2.1.0)
  • letter_opener (0.0.2)
  • libv8 (3.3.10.4)
  • libwebsocket (0.1.5)
  • linecache19 (0.5.12)
  • listen (0.4.7)
  • mail (2.3.3)
  • maildir (2.0.0)
  • mailman (0.5.2)
  • memcache-client (1.8.5)
  • metaclass (0.0.1)
  • mime-types (1.18)
  • mini_magick (3.4)
  • mocha (0.11.3)
  • multi_json (1.0.4)
  • net-scp (1.0.4)
  • net-sftp (2.0.5)
  • net-ssh (2.3.0)
  • net-ssh-gateway (1.1.0)
  • nifty-generators (0.4.6)
  • nilify_blanks (1.0.0)
  • nokogiri (1.5.3)
  • oink (0.9.3)
  • open4 (1.3.0)
  • options (2.3.0)
  • orm_adapter (0.0.7)
  • paper_trail (2.6.3)
  • passenger (3.0.12)
  • pdf-inspector (1.0.1)
  • pdf-reader (1.1.0)
  • pg (0.14.1)
  • polyamorous (0.5.0)
  • polyglot (0.3.3)
  • prawn (0.12.0)
  • prawnto_2 (0.2.5)
  • prickle (0.0.6)
  • progress_bar (0.4.0)
  • rack (1.3.6)
  • rack-cache (1.2)
  • rack-mini-profiler (0.1.19)
  • rack-mount (0.8.3)
  • rack-ssl (1.3.2)
  • rack-test (0.6.1)
  • rails (3.1.3)
  • rails-i18n (0.6.3)
  • rails_sql_views (0.8.0)
  • railties (3.1.3)
  • rake (0.9.2.2)
  • rb-fchange (0.0.5)
  • rb-fsevent (0.9.1)
  • rb-inotify (0.8.8)
  • rdoc (3.12)
  • rspec (2.9.0)
  • rspec-core (2.9.0)
  • rspec-expectations (2.9.1)
  • rspec-mocks (2.9.0)
  • rspec-rails (2.9.0)
  • ruby-debug-base19 (0.11.25)
  • ruby-debug19 (0.11.6)
  • ruby-hmac (0.4.0)
  • ruby-odbc (0.99994)
  • ruby-ole (1.2.11.3)
  • ruby-prof (0.10.8)
  • ruby-rc4 (0.1.5)
  • ruby_core_source (0.1.5)
  • rubyzip (0.9.9)
  • rvm-capistrano (1.2.7)
  • sass (3.1.15)
  • sass-rails (3.1.5)
  • selenium-webdriver (2.25.0)
  • simplecov (0.6.4)
  • simplecov-html (0.5.3)
  • spreadsheet (0.6.9)
  • sprockets (2.0.4)
  • squeel (1.0.7)
  • subexec (0.2.2)
  • term-ansicolor (1.0.7)
  • therubyracer (0.10.1)
  • thin (1.3.1)
  • thor (0.14.6)
  • tilt (1.3.3)
  • timecop (0.3.5)
  • treetop (1.4.10)
  • trucker (0.5.1)
  • ttfunk (1.0.3)
  • tzinfo (0.3.33)
  • uglifier (1.2.4)
  • uniform_notifier (1.1.0)
  • warden (1.1.1)
  • watu_table_builder (0.3.0)
  • whenever (0.7.3)
  • xpath (0.1.4)
  • xray (1.1)

Let me know if you need any more information.
Nicolas

@mhoran
Collaborator

If you're feeling lucky, check out pull request #428. I think I tracked down at least one of these issues. Note that the branch requires Capybara 2.0, though the changes could be backported to 0.13 if necessary.

@danielmorrison

@bryckbost and I had the same issue on a project. #428 changed it from hanging intermittently to failing early and then everything else errors with a Broken pipe (Errno::EPIPE). We're tracking that down now, and will update if we figure anything out.

@mhoran
Collaborator

@danielmorrison, are you experiencing this with the latest master? I merged in #428 yesterday.

Are the tests reliably failing at the same point, or in different points in the test suite? Do you get any output when the tests fail, for example "pure virtual method called terminate called without an active exception"?

Could you provide us with more information about your environment? Are you running on Linux or OS X? We don't have a reliable way to analyze core dumps at the moment, but I'm looking into adding a crash reporter to make this possible. If you're comfortable with gdb, you could try getting a backtrace from the core dump on your own.

@danielmorrison

Yep, we updated this afternoon. Same results on Travis-ci and OS X. We're see what we can grab, but it probably won't be today.

@danielmorrison

Looks like one test will fail with No response received from the server. (Capybara::Webkit::NoResponseError)` and then everything after will get a Broken Pipe. Nothing obvious why the initial error hits, but I'll keep looking!

@danielmorrison

Still don't have a "why" but found a workaround: If I toss in a sleep before the lines that give the No response error, it runs fine.

@mhoran
Collaborator

@danielmorrison, could you run the offending test with the webkit_debug driver and paste the output? That should help us get an idea about what's happening under the hood.

Are you on OS X? It'd be awesome if you could get a backtrace. You can set OS X and Linux to allow core dumps with ulimit -c unlimited. When capybara-webkit crashes, it should dump a core to /cores/core.PID, where PID is the PID of webkit_server, or to the current directory on Linux. Finally, running gdb bin/webkit_server <core> will get you in a GDB session, from which bt will return the current backtrace.

@mhoran
Collaborator

@danielmorrison, could you check out mhoran@a525f43?

@danielmorrison

No luck, same issue. I haven't had time to do anything more than try :webkit_debug yet. Sorry!

@mhoran
Collaborator

Thanks for testing. You're likely hitting a different bug now, as I am able to reproduce the original deadlock with capybara-webkit 0.13.0, but not with master.

Could you paste the :webkit_debug output of the failing scenario? We could at least see what the driver thinks is happening when it crashes.

@mhoran mhoran referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@mhoran mhoran referenced this issue from a commit in mhoran/capybara-webkit
@mhoran mhoran Test to verify fix for #399 8e80fe6
@mhoran
Collaborator

@danielmorrison, could you try out bca84f9? If you continue to experience segfaults, please follow the instructions in #380.

@nsocheleau

Hello @mhoran
Sorry, it took me a while to get back to you. I tried your pull request, I actually used the master as I understand you merged it. The issue is fixed for me. No more hanging.
Thanks.
Nicolas

@mattheworiordan

Hi @mhoran, sorry it has taken me so long to confirm as well, but so far so good. Unfortunately the upgrade to Capybara 2 has broken lots of things, so I have not yet had a chance to run the complete suite in full. As soon as I do, I will confirm here that the issue is fixed.

@barmstrong

Downgrading capybara-webkit from 0.13.0 to 0.12.1 seemed to solve this for me.

This was in conjunction with capybara 1.1.2

@mhoran
Collaborator

@barmstrong, I'd recommend you try out the latest master, which fixes a number of segfaults in capybara-webkit. Note that master requires Capybara 2.0.

@coolo

An unrelated question: how about a prerelease for easier testing capybara-webkit master? I'm looking daily for a -webkit release that goes with 2.0 ;(

@larryh

I experienced the same thing that 'barmstrong' did, i.e. when I tried capybara-webkit 0.13.0 random cucumber tests would hang with a NoResponseError. This did not happen when I use Selenium or when I use capybara-webkit 0.12.1.

I know you're interested in moving forward, but I thought relaying this might give you some insight as to what is going on.

I am using capybara 1.1.3. I tried upgrading to capybara 2.0 but that broke a LOT of my cucumber tests, so I backed down to 1.1.3 for now.

Thanks for working on this. I know it must be incredibly complex and (dare I say) a royal pain in the %$#.

@mhoran
Collaborator

Thanks for the report. Your issue has hopefully been fixed on master. We don't plan to backport these fixes to Capybara 1.x, and instead encourage users to upgrade to Capybara 2.0.

@kamarcum

Bumping to master fixed this for me. :+1:

@mhoran
Collaborator

@mattheworiordan, how is your Capybara 2.0 upgrade going? We just released capybara-webkit 0.14.0 which should resolve this issue.

@taavo

Just wanted to say thanks for wrestling with this, mhoran. 0.13 was a bumpy ride for me, with regular but inconsistent crashes. So far, 0.14 is beautiful--and my suite's running about 30% faster for some reason. Many thanks.

@mattheworiordan

@mhoran, apologies for the delay, I got about half way through and then got pulled into an urgent project. As soon as I have some downtime, I'll complete that upgrade and give you an update. However, so far it looks good, not had any problems.

@larryh

Like taavo, I would also like to say "thanks" to mhoran and the rest of the crew at thoughtbot for working - and following up - on this. And to mattheworiordan for the effort he has put into this problem.

I just upgraded capybara from 1.1.3 to 2.0.2 and capybara-webkit from 0.12.1 to 0.14.0. So far it seems pretty good, but lot of my tests are being skipped because of "ambiguous matches" introduced in Capy 2.0 - which means it's hard for me to experience server timeouts because a lot of my tests aren't being run.

I will tackle that problem and return to this thread to let you (and future visitors) know how the new version is doing.

Once again, thanks for your efforts!

@mattheworiordan

@mhoran, I am just dropping you a quick line to say I've still not had time to finish the migration to Capybara 2. Te suite is very large, so is taking a long time, and I have to do this in the background as we have various priorities. I thank you again for your effort, and apologise I cannot throw more time at it myself right now to give you the feedback you deserve.

@larryh

Hello again. Just wanted to (finally) check back in and report that I'm using 0.14.1 and it works like a charm! Thanks a lot to everyone who works on this gem!

@DimaSamodurov

The capybara-webkit 1.0 randomly hang on entire suite for me as well.

explicit use of Thin handler helped. Added to env.rb:

Capybara.server do |app, port|
  require 'rack/handler/thin'
  Rack::Handler::Thin.run(app, :Port => port)
end
@betelgeuse

@DimaSamodurov does your upgrade to capybara-webkit 1.0 also upgrade your capybara over major versions? Thin support was dropped from capybara a while back jnicklas/capybara#920

@DimaSamodurov

I use capybara 2.1. This is currently a recent version, not a master though. They removed default Thin handler, but not prohibited to use it in general. I don't have intention to suggest a specific server for tests. I just shared my context of the issue. May be differences of handling connections by Webrick and Thin could point to the real source of the issue.

@mhoran
Collaborator

Just a warning, support for Thin was dropped due to the fact that it is not thread safe. You may run in to some exciting new issues by using Thin as your Rack server.

If possible, could you let us know if this is a new issue in 1.0, or if it is present in 0.14.2 as well? Note that 0.14.2 is not compatible with Capybara 2.1 so I understand if this is not possible.

@DimaSamodurov

I have been using 0.14.2 with capybara 2.0.2 patched with several fixes and back-ports from 2.1 for several months and did not get any hangups. I tried Thin as a workaround to be able to upgrade to Capybara 2,1, Capybara-wekit 1.0, Qt4.8. We don't use threads intensively but thanks for the reminder, I'll keep it i mind. I don't have clear idea how to debug this particular issue, because it happens only in a batch but i would experiment..

@jferris
Admin

I haven't seen this issue in a long time, and the consistent reports have ceased to come in, so I'm going to consider the original issue resolved.

If capybara-webkit starts hanging on you, please open a new issue with as much information as possible, including debug logs.

@jferris jferris closed this
@redbar0n

If it is the same problem I was having, then it's an issue with the Webkit implementation that Qt 4 uses on OSX. The solution is to upgrade to Qt 5 which uses a newer version that doesn't throw these kinds of errors when trying to play MP4 videos, for instance.

See this blog post for details about the problem and solution: http://magnemg.tumblr.com/post/113251336220/how-to-solve-a-capybara-webkit-and-video-js

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.