search

thoughtbot / capybara-webkit

A Capybara driver for headless WebKit to test JavaScript web apps
https://thoughtbot.com/open-source
MIT License
1.97k stars 427 forks source link

Errno::ECONNRESET: Connection reset by peer on Ubuntu 13.04 #540

Closed albertosaurus closed 7 years ago

albertosaurus commented 11 years ago

capybara-webkit 1.0.0 capybara 2.0.1

All my capybara-webkit specs are failing with the above error. In addition, I'm getting

Errno::EPIPE: Broken pipe
  occurred at path_to_gemset/gems/capybara-webkit-1.0.0/lib/capybara/webkit/connection.rb:28:in `write'

Sadly, this is all the output I got, even with webkit_debug.

This originally happened with the default 4.8.4 Qt installed with Ubuntu. I got the same result when building the gem against Qt 5.0.2 installed from http://qt-project.org/download

I suspect this may be related to https://github.com/thoughtbot/capybara-webkit/issues/435 and/or https://github.com/thoughtbot/capybara-webkit/issues/535

albertosaurus commented 11 years ago

Two updates:

1) I've determined that webkit_server crashes when the spec tries to do a "Reset"

2) I tried compiling Qt4.8.4 from source and then building the gem against that Qt. Same result.

greyblake commented 11 years ago

I had similar when I ran specs in different application, but they use same Capybara.port. Make sure that you don't hard code it.

albertosaurus commented 11 years ago

In my case, running a single spec is enough to break it.

mhoran commented 11 years ago

@albertosaurus, could you extract a test case which reliably causes this failure?

albertosaurus commented 11 years ago

@mhoran, I can try, but that would be very difficult. Some more strangeness:

1) In another application, capybara-webkit is working without a glitch (compiled against the default webkit 4.8.4 in Ubuntu. 2) I tried compiling against Qt 5.1 that came out last week. That almost works, in a sense that webkit crashes only in the middle of the test suite rather than immediately. But I can run the individual specs.

thaichors3000 commented 11 years ago

I have faced the same issue.

capybara-webkit 1.0.0 capybara 2.1.0 ubuntu 13.04 qt 5.0.1

spec in my engine rails failed with the same error only when I try to visit main_app.root_path or main_app.root_url. I run it with :webkit_debug, still there is no more error message.

bradgessler commented 11 years ago

I also get Broken pipe errors running against qt5.

capybara-webkit 1.0.0
capybara 2.1.0
OS X 10.8.4
qt 5.1.0
bradgessler commented 11 years ago

@mhoran is capaybara-webkit designed to run with QT5? I did a lot of Googling around and its not very clear to me. Everything I've seen points to qt >= 4.8.4 but I can't find anything that reports the level of testing against qt 5+.

mhoran commented 11 years ago

capybara-webkit is tested against, and should be compatible with Qt 5.0.

bradgessler commented 11 years ago

Thanks, just updated the wiki install instructions to use brew install qt5 for 10.8+ so that folks be on the latest version of Qt.

I'll keep futzing around with this and hopefully extract a reliable test case.

habdelra commented 11 years ago

I'm encountering the same issue:

capybara-webkit 1.0.0 capybara 2.1.0 OS X 10.8.4 qt 5.1.0

The crashlog is available in a gist here: https://gist.github.com/habdelra/6532065. Oddly it looks related to loading the fonts in QTWebKit--which is actually "museo_sans" for our application...

bradgessler commented 11 years ago

@habdelra I'm also using external fonts, but dont know how to access the crash log. I looked at https://github.com/thoughtbot/capybara-webkit/wiki/Reporting-Crashes but found no instruction. Could you update that wiki page on how to do this so I can run the suite again and see what I get?

habdelra commented 11 years ago

@bradgessler sure thing. Just added it.

habdelra commented 11 years ago

As a note: a switched back to using qt (ver 4.8.5) and that fixed things. So I'm thinking the problem is really qtwebkit....

jessieay commented 11 years ago

I was just having this issue on a branch. Master was working properly so I did a git reset of my Gemfile.lock to return all my gems back to the versions that were working. This fixed the issue on my branch.

I am using qt 4.8.5.

Here is the diff of my Gemfile.lock when I reset it back to what was working (working gem versions in green). Hope this helps some of you get back to a working state.

screen shot 2013-09-18 at 2 25 47 pm screen shot 2013-09-18 at 2 25 57 pm

rosskevin commented 11 years ago

I'm seeing this problem quite often too on our Ubuntu 13.04 CI server, running:

qt 5
capybara-webkit (1.0.0)
capybara (2.1.0)
selenium-webdriver (2.35.1)

I am running :webkit_debug but no useful information is presented, and the crash reporting page above doesn't discuss how to grab/contribute any useful information about the crash from a linux env.

I had tried upgrading server packages, and moving from qt4 to qt5, with seemingly no affect. Builds fail about 60% of the time, with a rebuild (no changes) succeeding. Please let me know what I can do to contribute some information from the linux env.

UPDATE: Unable to duplicate on OSX running qt 4.8.5, I have reverted the Ubuntu qt version, but still see it there. webkit_server: Fatal IO error: client killed

smeyfroi commented 11 years ago

I've been seeing the same in a vagrant/ubuntu12.04/qt4.8.1 environment: unable to run the entire set of feature tests.

But I think (hope!) it's been fixed by giving the vagrant VM more memory… a lot more.

Is it possible that these failures are simply a result of the webkit process running out of memory? Webit can be quite heavy when running complicated tests in a memory-constrained dev vagrant box.

rosskevin commented 11 years ago

@smeyfroi I reverted to using non-parallel tests, but perhaps you are onto something. Our tests would fail randomly towards the end, not beginning.

Unfortunately I can't revisit this issue for a while, but I'll keep track of this in case that works when I have time to take another shot at it.

smeyfroi commented 11 years ago

@rosskevin I'm not using parallel tests (on my todo list!) but I noticed that the 768MB I'd allocated to my vagrant VM wasn't really enough after installing yet more dependencies to my project. Makes sense I guess.

My test runs were getting noticeably sloooooower towards the end of a run: I imagine the VM was perhaps swapping like crazy.

Everything is working very nicely now: well over 100 webkit feature tests with complicated JS and SVG stuff chugging along just fine. Errr, fingers crossed.

daanemanz commented 9 years ago

@smeyfroi I have tried setting up a Vagrant VM with 8GB of memory, but I'm still running into the same issue on Ubuntu 14.04.

$ cat /proc/meminfo
MemTotal:        8176852 kB

I did find an interesting entry in the system logs:

[ 2687.245928] traps: webkit_server[3261] general protection ip:7f83a190f787 sp:7fff8c16bfe0 error:0 in libQtWebKit.so.4.10.2[7f83a0430000+1fc9000]

Has anyone seen the same message?

rosskevin commented 9 years ago

So, I just went back and tried parallel_tests after some time and many updates to libraries. Unfortunately, the dreaded random (Errno::EPIPE) is still there.

I'm on:

Ubuntu 14.04.1 LTS
libqt5webkit5-dev 5.1.1-1ubuntu8
qtdeclarative5-dev 5.2.1-3ubuntu15.1

Gemfile.lock - related gems:

    capybara (2.4.4)
    capybara-webkit (1.4.1)

Here's a gist of my configuration. Perhaps the relevant parts of potential misconfiguration could be:

# try to get a unique port, important for parallels tests
# if ENV['TEST_ENV_NUMBER']
test_env_number = ENV['TEST_ENV_NUMBER']
test_env_number ||= 1
test_port = 9887 + test_env_number.to_i
#test_port += 1 while is_port_open?(@port) and not is_running_on_port?(@port)

puts "Capybara::Server.port: #{test_port} for test process: #{test_env_number}"
Capybara.server_port = test_port
# end

if $headless_server.nil?

  # Unnecessary on mac, see https://github.com/leonid-shevtsov/headless/issues/31#issuecomment-8933108
  if !OS.mac?
    require 'headless'
    # allow display autopick (by default)
    # allow each headless to destroy_at_exit (by default)
    # allow each process to have their own headless by setting reuse: false
    # $headless_server = Headless.new(reuse: false)
    $headless_server = Headless.new(reuse: true, destroy_at_exit: false)
    $headless_server.start

    puts "Process[#{Process.pid}] started headless server display: #{$headless_server.display}"
  end
end

at_exit do
  unless $headless_server.nil?
    puts "Process[#{Process.pid}] destroying headless server on display: #{$headless_server.display}"
    $headless_server.destroy
  end
end

Here's a full stack trace from a broken test that works in synchronous mode:

Message:

    Broken pipe (Errno::EPIPE)
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/capybara-webkit-1.4.1/lib/capybara/webkit/connection.rb:30:in `write'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/capybara-webkit-1.4.1/lib/capybara/webkit/connection.rb:30:in `puts'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/capybara-webkit-1.4.1/lib/capybara/webkit/connection.rb:30:in `puts'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/capybara-webkit-1.4.1/lib/capybara/webkit/browser.rb:204:in `command'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/capybara-webkit-1.4.1/lib/capybara/webkit/browser.rb:38:in `reset!'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/capybara-webkit-1.4.1/lib/capybara/webkit/driver.rb:251:in `reset!'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/capybara-2.4.4/lib/capybara/session.rb:103:in `reset!'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/capybara-2.4.4/lib/capybara.rb:257:in `block in reset_sessions!'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/capybara-2.4.4/lib/capybara.rb:257:in `each'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/capybara-2.4.4/lib/capybara.rb:257:in `reset_sessions!'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/capybara-2.4.4/lib/capybara/cucumber.rb:8:in `After'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/core_ext/instance_exec.rb:36:in `cucumber_instance_exec'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/rb_support/rb_hook.rb:14:in `invoke'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:114:in `invoke'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:108:in `block in execute_after'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:107:in `reverse_each'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:107:in `execute_after'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:19:in `after'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:112:in `block in fire_hook'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:111:in `each'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:111:in `fire_hook'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:113:in `after'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:100:in `before_and_after'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:82:in `block in with_hooks'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:120:in `call'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:120:in `block (3 levels) in around'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:9:in `block in around'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:94:in `call'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:94:in `block (3 levels) in execute_around'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/database_cleaner-1.4.0/lib/database_cleaner/generic/base.rb:15:in `cleaning'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/database_cleaner-1.4.0/lib/database_cleaner/base.rb:92:in `cleaning'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/database_cleaner-1.4.0/lib/database_cleaner/configuration.rb:86:in `block (2 levels) in cleaning'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/database_cleaner-1.4.0/lib/database_cleaner/configuration.rb:87:in `call'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/database_cleaner-1.4.0/lib/database_cleaner/configuration.rb:87:in `cleaning'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/database_cleaner-1.4.0/lib/database_cleaner/cucumber.rb:2:in `block in <top (required)>'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/core_ext/instance_exec.rb:48:in `instance_exec'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/core_ext/instance_exec.rb:48:in `block in cucumber_instance_exec'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/core_ext/instance_exec.rb:69:in `cucumber_run_with_backtrace_filtering'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/core_ext/instance_exec.rb:36:in `cucumber_instance_exec'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/rb_support/rb_hook.rb:14:in `invoke'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:114:in `invoke'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:93:in `block (2 levels) in execute_around'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:97:in `call'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:97:in `execute_around'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:8:in `around'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:119:in `block (2 levels) in around'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:123:in `call'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:123:in `around'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:94:in `around'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:81:in `with_hooks'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/outline_table.rb:117:in `accept_plain'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/outline_table.rb:107:in `accept'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:138:in `block in visit_table_row'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:137:in `visit_table_row'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/outline_table.rb:27:in `block in accept'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/outline_table.rb:23:in `each'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/outline_table.rb:23:in `each_with_index'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/outline_table.rb:23:in `accept'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:90:in `block in visit_outline_table'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:89:in `visit_outline_table'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/examples.rb:25:in `accept'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:80:in `block in visit_examples'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:79:in `visit_examples'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/scenario_outline.rb:19:in `block in accept'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/scenario_outline.rb:18:in `each'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/scenario_outline.rb:18:in `accept'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:74:in `block in visit_examples_array'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:73:in `visit_examples_array'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/scenario_outline.rb:45:in `accept'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:58:in `block in visit_feature_element'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:57:in `visit_feature_element'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/feature.rb:38:in `block in accept'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/feature.rb:37:in `each'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/feature.rb:37:in `accept'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:27:in `block in visit_feature'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:26:in `visit_feature'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/features.rb:28:in `block in accept'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/features.rb:17:in `each'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/features.rb:17:in `each'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/features.rb:27:in `accept'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:21:in `block in visit_features'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:20:in `visit_features'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:49:in `run!'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/lib/cucumber/cli/main.rb:47:in `execute!'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/gems/cucumber-1.3.18/bin/cucumber:13:in `<top (required)>'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/bin/cucumber:23:in `load'
/home/apps/.rvm/gems/ruby-2.2.0@af_core/bin/cucumber:23:in `<main>'

This is killing me; single-process runs are up to 45 minutes, while multi-process is under 10 minutes.

Capybara.reset_sessions! appears to be a place that a workaround could be instituted, perhaps catch/ignore, remove from pool?

How can I help? Any thoughts on a workaround or retry or reset of a browser connection?

rosskevin commented 9 years ago

Related issues could be #68. Running with :webkit_debug now to see if anything interesting turns up.

mhoran commented 9 years ago

Hey @rosskevin, it's certainly possible that the Headless gem is mismanaging the Xvfb server that the webkit_server process is running in. This would cause the webkit_server process to crash. I'd recommend wrapping your parallel executor in xvfb-run, as documented in the README.

rosskevin commented 9 years ago

@mhoran - As feedback from :webkit_debug, it was mentioned somewhere, and now I can confirm that when running with :webkit_debug, I have no (Errno::EPIPE) failures. Perhaps that is something we can work with?

I'll try xvfb-run without headless now.

rosskevin commented 9 years ago

@mhoran - while I have other errors, I do not have (Errno::EPIPE) with xvfb-run. I'll try to go down this path and see if I can make it work.

sethjeffery commented 9 years ago

Hello, we have been experiencing this Broken Pipe error for a long time. We also use paralellism (through CircleCI). I tried running with :webkit_debug, but still received the failures.

The nature of the problem appears to be a race condition, we can never find a way to effectively reproduce it, save from just re-running our tests until it randomly happens again. (Which appears to be about 1 in 5.)

Once the error happens, all following tests fail, but it's not necessarily the first test that fails. Sometimes 341 tests fail, then 376, then 381. However I do notice that the failure happens towards the start, rather than toward the end of the tests.

Here's some of the debug output from the most recent test running through :webkit-debug:

Wrote response true "http://127.0.0.1:54428/en/classes/54eb0dcc4447582a54001df7" 
Received "Reset()" 
Started "Reset()" 
Finished "Reset()" with response "Success()" 
Wrote response true "" 
Received "FindXpath(/html/body/*)" 
Started "FindXpath(/html/body/*)" 
Finished "FindXpath(/html/body/*)" with response "Success()" 
Wrote response true "" 
.Received "AllowUrl(connect.facebook.net)" 
Started "AllowUrl(connect.facebook.net)" 
Finished "AllowUrl(connect.facebook.net)" with response "Success()" 
Wrote response true "" 
Received "AllowUrl(cdn.mxpnl.com)" 
Started "AllowUrl(cdn.mxpnl.com)" 
Finished "AllowUrl(cdn.mxpnl.com)" with response "Success()" 
Wrote response true "" 
Received "AllowUrl(fonts.googleapis.com)" 
Started "AllowUrl(fonts.googleapis.com)" 
Finished "AllowUrl(fonts.googleapis.com)" with response "Success()" 
Wrote response true "" 
Received "AllowUrl(assets.zendesk.com)" 
Started "AllowUrl(assets.zendesk.com)" 
Finished "AllowUrl(assets.zendesk.com)" with response "Success()" 
Wrote response true "" 
Received "BlockUrl(browser-update.org)" 
Started "BlockUrl(browser-update.org)" 
Finished "BlockUrl(browser-update.org)" with response "Success()" 
Wrote response true "" 
Received "SetCookie(quipper_auth_token=PPWVvJc9hhzTNeZOD99afs1TKxQyOOJZFXm2Rkjfhu7wPHAIfCE3ww8wygHs9K4NwBlFDYztRyaJZtDcfa5miQ%3D%3D; path=/; domain=127.0.0.1;)" 
Started "SetCookie(quipper_auth_token=PPWVvJc9hhzTNeZOD99afs1TKxQyOOJZFXm2Rkjfhu7wPHAIfCE3ww8wygHs9K4NwBlFDYztRyaJZtDcfa5miQ%3D%3D; path=/; domain=127.0.0.1;)" 
Finished "SetCookie(quipper_auth_token=PPWVvJc9hhzTNeZOD99afs1TKxQyOOJZFXm2Rkjfhu7wPHAIfCE3ww8wygHs9K4NwBlFDYztRyaJZtDcfa5miQ%3D%3D; path=/; domain=127.0.0.1;)" with response "Success()" 
Wrote response true "" 
Received "SetCookie(quipper_auth_token=8CVnnF7jb3GuFNmg4wCCeeQw8LaFBbY7xiDULbUrLLao2H%2BOXft8x8LTSDPYPeVv48JKAnoJ7lLVU5I1n5itEQ%3D%3D; path=/; domain=127.0.0.1;)" 
Started "SetCookie(quipper_auth_token=8CVnnF7jb3GuFNmg4wCCeeQw8LaFBbY7xiDULbUrLLao2H%2BOXft8x8LTSDPYPeVv48JKAnoJ7lLVU5I1n5itEQ%3D%3D; path=/; domain=127.0.0.1;)" 
Finished "SetCookie(quipper_auth_token=8CVnnF7jb3GuFNmg4wCCeeQw8LaFBbY7xiDULbUrLLao2H%2BOXft8x8LTSDPYPeVv48JKAnoJ7lLVU5I1n5itEQ%3D%3D; path=/; domain=127.0.0.1;)" with response "Success()" 
Wrote response true "" 
Received "Visit(http://127.0.0.1:54428/en/classes/54eb0dcd4447582a54001e20)" 
Started "Visit(http://127.0.0.1:54428/en/classes/54eb0dcd4447582a54001e20)" 
Load started 
"Visit(http://127.0.0.1:54428/en/classes/54eb0dcd4447582a54001e20)" started page load 
Started request to "http://127.0.0.1:54428/en/classes/54eb0dcd4447582a54001e20" 
Finished "Visit(http://127.0.0.1:54428/en/classes/54eb0dcd4447582a54001e20)" with response "Success()" 
Started request to "http://127.0.0.1:54428/assets/qstrap.css" 
Started request to "http://127.0.0.1:54428/assets/application.css" 
Started request to "http://127.0.0.1:54428/assets/application.js" 
Received 200 from "http://127.0.0.1:54428/en/classes/54eb0dcd4447582a54001e20" 
Received 304 from "http://127.0.0.1:54428/assets/application.css" 
Received 304 from "http://127.0.0.1:54428/assets/application.js" 
Received 304 from "http://127.0.0.1:54428/assets/qstrap.css" 

  An error occurred in an after hook
    Errno::EPIPE: Broken pipe
    occurred at /home/ubuntu/qlink/vendor/bundle/ruby/2.2.0/gems/capybara-webkit-1.4.1/lib/capybara/webkit/connection.rb:30:in `write'

  An error occurred in an after hook
    Errno::EPIPE: Broken pipe
    occurred at /home/ubuntu/qlink/vendor/bundle/ruby/2.2.0/gems/capybara-webkit-1.4.1/lib/capybara/webkit/connection.rb:30:in `write'

(After which we got about 300 repetitions of "An error occurred in an after hook...")

dirkkelly commented 9 years ago

Cheers @mhoran!

We've occasionally seen this issue on CircleCI, the other day it started happening repeatedly.

Wrapping our runner in xvfb-run (as mentioned in the readme) fixed the repeated failures, we haven't seen a sporadic broken pipe since then.

There's an example of our circle.yml in our related blog https://www.interexchange.org/articles/engineering/2015/02/24/circleci-capybara-xvfb/

kimh commented 9 years ago

Hi, team.

It's been a while since the last update in the PR, but recently I hit this issue and cannot fix, so I want to have some advise for how to debug. Here is my environment.

Ubuntu 12.04
Qt 5.3
Ruby 2.2.2p95
capybara-webkit 1.5.1
capybara 2.4.4
rspec 3.2.0

I randomly get the Errno::EPIPE: Broken pipe error just like others. I've turned on webkit_debug and this is what I got.

Wrote response true "input"
Received "Node.attribute"
Started "Node.attribute"
Finished "Node.attribute" with response "Success(true)"
Wrote response true "true"
Received "Reset()"
Started "Reset()"

  An error occurred in an after hook
    Errno::EPIPE: Broken pipe
    occurred at /home/ubuntu/*******/vendor/bundle/ruby/2.2.0/gems/capybara-webkit-1.5.1/lib/capybara/webkit/connection.rb:30:in `write'

and all subsequent tests fail with the same error, so I think webkit-server is crashed with Reset().

I tried to wrap my rspec command with xvfb-run but no luck.

Any idea to debug further?

I think there used to be a way to get stacktrace of webkit-server with breakpad branch but does that still work?

Thank you for you help.

calleluks commented 9 years ago

Hey @kimh, thanks for reporting this!

Could this be a duplicate of #777?

Could you try using the jf-reset-crash branch to see if that resolves the issue for you?

kimh commented 9 years ago

@calleerlandsson

I don't think this is the duplicate of #777. We started having a issue about a month ago while #777 was introduced only recently. I believe this is still part of #540.

I'm from CircleCI and my customer had the issue, but I can't reproduce this on my side. I'll ask them to try jf-reset-crash branch when the customer had the issue next time.

calebhearth commented 9 years ago

I think you meant @calleerlandsson

kimh commented 9 years ago

Ah, you are right @calebthompson. Sorry about that!!

calleluks commented 9 years ago

In #777, the offending commit seems to be f8f2048 which is also in the 1.5.1 release in the form of 0fde455, so I'm not sure it can be ruled out.

tmertens commented 9 years ago

I am seeing this issue as well, quite reproducibly I am afraid. I am working on getting our build running in Jenkins (currently we are using Solano, which only occasionally sees this error) and the failure occurs 100% of the time, usually after any single test completes. I am happy to dig into this if I can get some support, this is a high priority issue for me and seems many others would also benefit from finally resolving this.

CI Environment (failing):

ubuntu 14.04
Qt 5.2.1
capybara 2.4.4
gem 'capybara-webkit', git: 'git@github.com:thoughtbot/capybara-webkit.git', branch: 'jf-reset-crash'

Local Environment (tests work):

OS X 10.10.3
Qt 5.4.2
capybara 2.4.4
gem 'capybara-webkit', git: 'git@github.com:thoughtbot/capybara-webkit.git', branch: 'jf-reset-crash'

So, I added some additional logging around sending of requests:

module Capybara
  module Webkit
    module ExtendedDebug
      def puts(string)
        @output_target << "putting: #{string}\n"
        super
      end

      def print(string)
        @output_target << "printing: #{string}\n"
        super
      end
    end

    class Connection
      prepend ExtendedDebug
    end
  end
end

Initially, at the end of any given test, here is what I see when running this code on my mac (passing):

putting: Reset
putting: 0
Received "Reset()"
Started "Reset()"
Aborting request ...

Here we can see that Capybara::Webkit::Browser#command is working normally. It sends the command, followed by the argument count (0), and then we get debug messages back from the webkit server when using the :webkit_debug driver.

Now, when I run this same code on Jenkins, I see:

Received 200 from "http://127.0.0.1:33795/assets/v3/application.js" 
putting: Reset
  An error occurred in an after hook
    Errno::EPIPE: Broken pipe
    occurred at /var/lib/jenkins/.rvm/gems/ruby-2.1.5/bundler/gems/capybara-webkit-d287acfef3ec/lib/capybara/webkit/connection.rb:36:in `write'

Like @sethjeffery, the last command prior to Reset was Visit. Whether or not that is relevant I am not sure but it seems highly suspect that the issue only occurs sometimes for most people, and I have even seen some reports where adding a wait after their tests resolves the issue. I suspect there is some asynchronous javascript or something else happening in the background that is causing the failure to occur.

That being said, it is interesting that only the command is sent and not the arguments, which indicates either a) the webkit-server has already died and/or otherwise fails to serve the request when the reset command message is sent or b) it dies while processing the argument.

tmertens commented 9 years ago

After further investigation, there is definitely a failure occurring prior to the Broken pipe exception, but it is not reported (by rspec) until the end of the tests. I've seen a couple different error:

     EOFError:
       end of file reached
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/bundler/gems/capybara-webkit-d287acfef3ec/lib/capybara/webkit/connection.rb:55:in `read_nonblock'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/bundler/gems/capybara-webkit-d287acfef3ec/lib/capybara/webkit/connection.rb:55:in `read'
     Errno::ECONNRESET:
       Connection reset by peer
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/bundler/gems/capybara-webkit-d287acfef3ec/lib/capybara/webkit/connection.rb:55:in `read_nonblock'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/bundler/gems/capybara-webkit-d287acfef3ec/lib/capybara/webkit/connection.rb:55:in `read'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/bundler/gems/capybara-webkit-d287acfef3ec/lib/capybara/webkit/connection.rb:46:in `gets'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/bundler/gems/capybara-webkit-d287acfef3ec/lib/capybara/webkit/browser.rb:287:in `check'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/bundler/gems/capybara-webkit-d287acfef3ec/lib/capybara/webkit/browser.rb:210:in `command'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/bundler/gems/capybara-webkit-d287acfef3ec/lib/capybara/webkit/browser.rb:34:in `find_css'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/bundler/gems/capybara-webkit-d287acfef3ec/lib/capybara/webkit/driver.rb:55:in `find_css'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/capybara-2.4.4/lib/capybara/node/base.rb:102:in `find_css'

Let me know if I should log this as a new issue, it's unclear whether or not it is the same as the original issue as started this thread.

jferris commented 9 years ago

@tmertens I just released 1.5.2 with some crash fixes. Can you give that a shot?

tmertens commented 9 years ago

Thanks @jferris I tried it to no effect:

Started request to "http://127.0.0.1:52700/assets/v3/home2/blue-banner-bg.jpg" 
Started request to "http://127.0.0.1:52700/assets/v3/brand/logo-light@2x.png" 
Started request to "http://127.0.0.1:52700/assets/v3/tv2/green-arrow-left.png" 
Started request to "http://127.0.0.1:52700/assets/v3/home2/icons/ico-clock.png" 
Started request to "http://127.0.0.1:52700/assets/v3/home2/icons/ico-bank.png" 
Started request to "http://127.0.0.1:52700/assets/v3/home2/icons/ico-chart.png" 
Started request to "http://127.0.0.1:52700/assets/v3/home2/logo-icon-dark.png" 
Started request to "http://127.0.0.1:52700/assets/v3/home2/steps.png" 
Started request to "http://127.0.0.1:52700/assets/v3/home2/press-logos.png" 
Started request to "http://127.0.0.1:52700/assets/v3/home2/team-photo@2x.jpg" 
Started request to "http://127.0.0.1:52700/assets/v3/home2/icons/ico-chart2.png" 
Started request to "http://127.0.0.1:52700/assets/v3/home2/icons/ico-lock.png" 
Started request to "http://127.0.0.1:52700/assets/v3/home2/icons/ico-support.png" 
Started request to "http://127.0.0.1:52700/assets/v3/brand/footer-logo@2x.png" 
Started request to "http://127.0.0.1:52700/assets/v3/application.js" 
Received 200 from "http://127.0.0.1:52700/assets/v3/application.js" 
Received 200 from "http://127.0.0.1:52700/assets/v3/apply-slider.js" 
Received 200 from "http://127.0.0.1:52700/assets/v3/homepage.js" 
Received 200 from "http://127.0.0.1:52700/assets/v3/home2/blue-banner-bg.jpg" 
Received 200 from "http://127.0.0.1:52700/assets/v3/brand/logo-light@2x.png" 
Received 200 from "http://127.0.0.1:52700/assets/v3/tv2/green-arrow-left.png" 
Received 200 from "http://127.0.0.1:52700/assets/v3/home2/icons/ico-clock.png" 
Received 200 from "http://127.0.0.1:52700/assets/v3/home2/team-photo@2x.jpg" 
Received 200 from "http://127.0.0.1:52700/assets/v3/home2/icons/ico-chart.png" 
Received 200 from "http://127.0.0.1:52700/assets/v3/home2/icons/ico-bank.png" 
Received 200 from "http://127.0.0.1:52700/assets/v3/home2/steps.png" 
Received 200 from "http://127.0.0.1:52700/assets/v3/home2/logo-icon-dark.png" 
Received 200 from "http://127.0.0.1:52700/assets/v3/home2/press-logos.png" 
Received 200 from "http://127.0.0.1:52700/assets/v3/application.js" 
Received 200 from "http://127.0.0.1:52700/assets/v3/home2/icons/ico-chart2.png" 
Received 200 from "http://127.0.0.1:52700/assets/v3/home2/icons/ico-lock.png" 
Received 200 from "http://127.0.0.1:52700/assets/v3/brand/footer-logo@2x.png" 
Received 200 from "http://127.0.0.1:52700/assets/v3/home2/icons/ico-support.png" 
putting: Reset

  An error occurred in an after hook
    Errno::EPIPE: Broken pipe
    occurred at /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/capybara-webkit-1.5.2/lib/capybara/webkit/connection.rb:30:in `write'

and rspec results show:

Failures:

  1) Content pages redirect /index to /
     Failure/Error: page.load
     EOFError:
       end of file reached
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/capybara-webkit-1.5.2/lib/capybara/webkit/connection.rb:49:in `read_nonblock'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/capybara-webkit-1.5.2/lib/capybara/webkit/connection.rb:49:in `read'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/capybara-webkit-1.5.2/lib/capybara/webkit/connection.rb:40:in `gets'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/capybara-webkit-1.5.2/lib/capybara/webkit/browser.rb:283:in `check'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/capybara-webkit-1.5.2/lib/capybara/webkit/browser.rb:210:in `command'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/capybara-webkit-1.5.2/lib/capybara/webkit/browser.rb:18:in `visit'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/capybara-webkit-1.5.2/lib/capybara/webkit/driver.rb:41:in `visit'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/capybara-2.4.4/lib/capybara/session.rb:227:in `visit'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/capybara-2.4.4/lib/capybara/dsl.rb:51:in `block (2 levels) in <module:DSL>'
     # /var/lib/jenkins/.rvm/gems/ruby-2.1.5/gems/site_prism-2.6/lib/site_prism/page.rb:10:in `load'
     # ./spec/acceptance/en-US/content_page_spec.rb:13:in `block (3 levels) in <top (required)>'
     # ./spec/acceptance/en-US/content_page_spec.rb:12:in `tap'
     # ./spec/acceptance/en-US/content_page_spec.rb:12:in `block (2 levels) in <top (required)>'
     # ./spec/rails_helper.rb:139:in `block (2 levels) in <top (required)>'
tmertens commented 9 years ago

@jferris It seems that this is related in some way to the loading of application.js. The crash always occurs after the reply is destroyed. Given the debug code:

void WebPageManager::replyDestroyed(QObject *reply) {
  logger() << "handling reply destroyed for" << ((QNetworkReply *) reply)->url().toString();
  m_pendingReplies.removeAll((QNetworkReply *) reply);
  logger() << "Pending Reply: " << m_pendingReplies.size();
  foreach(QNetworkReply *reply, m_pendingReplies) {
    logger() << "Pending Reply: " << reply->url().toString();
  }
}

The 'pending reply' list varies, but the reply being destroyed is always application.js:

handling reply destroyed for "http://127.0.0.1:33245/assets/v3/application.js" 
Pending Reply:  1 
Pending Reply:  "http://127.0.0.1:33245/assets/v3/brand/footer-logo@2x.png"
tmertens commented 9 years ago

@jferris I'm not sure where to go from here. If you can provide direction on what to look at, I would be happy to debug further. Thanks!

jferris commented 9 years ago

@tmertens could you link the full :webkit_debug log?

tmertens commented 9 years ago

@jferris I don't see much of use here, but here:

putting: EnableLogging
putting: 0
Finished "EnableLogging()" with response "Success()" 
Wrote response true "" 
putting: SetUnknownUrlMode
putting: 1
putting: 5
printing: block
Received "SetUnknownUrlMode(block)" 
Started "SetUnknownUrlMode(block)" 
Finished "SetUnknownUrlMode(block)" with response "Success()" 
Wrote response true "" 
putting: Visit
putting: 1
putting: 52
printing: http://127.0.0.1:58264/comparison/credit_cards
Received "Visit(http://127.0.0.1:58264/comparison/credit_cards)"
Started "Visit(http://127.0.0.1:58264/comparison/credit_cards)"
Load started 
"Visit(http://127.0.0.1:58264/comparison/credit_cards)" started page load
Started request to "http://127.0.0.1:58264/comparison/credit_cards"
Finished "Visit(http://127.0.0.1:58264/comparison/credit_cards)" with response "Success()"
Started request to "http://127.0.0.1:58264/assets/v3/application.css" 
Started request to "http://127.0.0.1:58264/assets/v3/application.js" 
Started request to "http://127.0.0.1:58264/assets/v3/apply-slider.js" 
[Report Only] Refused to load the script 'http://tags.extole.com/28268/core.js' because it violates the following Content Security Policy directive: "script-src https://* 'self' 'unsafe-inline' 'unsafe-eval' http://fast.fonts.com http://assets.zendesk.com".

handling reply finished 
Received "http://127.0.0.1:58264/comparison/credit_cards"
Received 200 from "http://127.0.0.1:58264/comparison/credit_cards"
reply finished "http://127.0.0.1:58264/comparison/credit_cards"
reply finished "https://fonts.googleapis.com/css?family=Open+Sans:400italic,400,300,600,700%7CGloria+Hallelujah" 
reply finished "http://tags.extole.com/28268/core.js" 
handling reply destroyed for "http://127.0.0.1:58264/comparison/credit_cards" 
Pending Reply:  3 
Pending Reply:  "http://127.0.0.1:58264/assets/v3/application.css" 
Pending Reply:  "http://127.0.0.1:58264/assets/v3/application.js" 
Pending Reply:  "http://127.0.0.1:58264/assets/v3/apply-slider.js" 
handling reply finished 
Received "http://127.0.0.1:58264/assets/v3/application.css" 
Received 200 from "http://127.0.0.1:58264/assets/v3/application.css" 
reply finished "http://127.0.0.1:58264/assets/v3/application.css" 
http://127.0.0.1:58264/comparison/credit_cards|50|Consider using 'dppx' units instead of 'dpi', as in CSS 'dpi' means dots-per-CSS-inch, not dots-per-physical-inch, so does not correspond to the actual 'dpi' of a screen. In media query expression: (-webkit-min-device-pixel-ratio: 1.5), (min-resolution: 138dpi), (min-resolution: 1.5dppx) 
http://127.0.0.1:58264/comparison/credit_cards|50|Consider using 'dppx' units instead of 'dpi', as in CSS 'dpi' means dots-per-CSS-inch, not dots-per-physical-inch, so does not correspond to the actual 'dpi' of a screen. In media query expression: (-webkit-min-device-pixel-ratio: 1.5), (min-resolution: 138dpi), (min-resolution: 1.5dppx) 
http://127.0.0.1:58264/comparison/credit_cards|50|Consider using 'dppx' units instead of 'dpi', as in CSS 'dpi' means dots-per-CSS-inch, not dots-per-physical-inch, so does not correspond to the actual 'dpi' of a screen. In media query expression: (-webkit-min-device-pixel-ratio: 1.5), (min-resolution: 138dpi), (min-resolution: 1.5dppx) 
http://127.0.0.1:58264/comparison/credit_cards|50|Consider using 'dppx' units instead of 'dpi', as in CSS 'dpi' means dots-per-CSS-inch, not dots-per-physical-inch, so does not correspond to the actual 'dpi' of a screen. In media query expression: (-webkit-min-device-pixel-ratio: 1.5), not all, not all, not all, (min-resolution: 138dpi), (min-resolution: 1.5dppx) 
http://127.0.0.1:58264/comparison/credit_cards|50|Consider using 'dppx' units instead of 'dpi', as in CSS 'dpi' means dots-per-CSS-inch, not dots-per-physical-inch, so does not correspond to the actual 'dpi' of a screen. In media query expression: (-webkit-min-device-pixel-ratio: 1.5), not all, not all, not all, (min-resolution: 138dpi), (min-resolution: 1.5dppx) 
[Report Only] Refused to load the image 'http://127.0.0.1:58264/assets/v3/brand/logo-light@2x.png' because it violates the following Content Security Policy directive: "img-src https://* data:".

[Report Only] Refused to load the image 'http://127.0.0.1:58264/assets/v3/fico-notices/fico-credit-notice.png' because it violates the following Content Security Policy directive: "img-src https://* data:".

[Report Only] Refused to load the image 'http://127.0.0.1:58264/assets/v3/brand/footer-logo@2x.png' because it violates the following Content Security Policy directive: "img-src https://* data:".

Started request to "http://127.0.0.1:58264/assets/v3/brand/logo-light@2x.png" 
Started request to "http://127.0.0.1:58264/assets/v3/fico-notices/fico-credit-notice.png" 
Started request to "http://127.0.0.1:58264/assets/v3/brand/footer-logo@2x.png" 
handling reply destroyed for "http://127.0.0.1:58264/assets/v3/application.css" 
Pending Reply:  5 
Pending Reply:  "http://127.0.0.1:58264/assets/v3/application.js" 
Pending Reply:  "http://127.0.0.1:58264/assets/v3/apply-slider.js" 
Pending Reply:  "http://127.0.0.1:58264/assets/v3/brand/logo-light@2x.png" 
Pending Reply:  "http://127.0.0.1:58264/assets/v3/fico-notices/fico-credit-notice.png" 
Pending Reply:  "http://127.0.0.1:58264/assets/v3/brand/footer-logo@2x.png" 
handling reply finished 
Received "http://127.0.0.1:58264/assets/v3/application.js" 
Received 200 from "http://127.0.0.1:58264/assets/v3/application.js" 
reply finished "http://127.0.0.1:58264/assets/v3/application.js" 
handling reply finished 
Received "http://127.0.0.1:58264/assets/v3/apply-slider.js" 
Received 200 from "http://127.0.0.1:58264/assets/v3/apply-slider.js" 
reply finished "http://127.0.0.1:58264/assets/v3/apply-slider.js" 
handling reply finished 
Received "http://127.0.0.1:58264/assets/v3/fico-notices/fico-credit-notice.png" 
Received 200 from "http://127.0.0.1:58264/assets/v3/fico-notices/fico-credit-notice.png" 
reply finished "http://127.0.0.1:58264/assets/v3/fico-notices/fico-credit-notice.png" 
handling reply finished 
Received "http://127.0.0.1:58264/assets/v3/brand/footer-logo@2x.png" 
Received 200 from "http://127.0.0.1:58264/assets/v3/brand/footer-logo@2x.png" 
reply finished "http://127.0.0.1:58264/assets/v3/brand/footer-logo@2x.png" 
handling reply finished 
Received "http://127.0.0.1:58264/assets/v3/brand/logo-light@2x.png" 
Received 200 from "http://127.0.0.1:58264/assets/v3/brand/logo-light@2x.png" 
reply finished "http://127.0.0.1:58264/assets/v3/brand/logo-light@2x.png" 
handling reply destroyed for "http://127.0.0.1:58264/assets/v3/application.js" 
Pending Reply:  0 
putting: Reset

  An error occurred in an after hook
    Errno::EPIPE: Broken pipe
    occurred at /var/lib/jenkins/.rvm/gems/ruby-2.1.5/bundler/gems/capybara-webkit-ecdc77d4736c/lib/capybara/webkit/connection.rb:36:in `write'
tmertens commented 9 years ago

@jferris Any suggestions/recommendations on how to proceed?

rosskevin commented 9 years ago

I want to mention that we haven't seen this error again since switching to xvfb-run on Ubuntu several months ago. We were receiving it consistently on every build prior to the switch.

tmertens commented 9 years ago

@rosskevin Would you mind posting more information about your environment? e.g. versions of Ubuntu, Qt, and capybara-webkit?

EDIT: I am using xvfb-run, but the build still fails every time.

rosskevin commented 9 years ago

@tmertens 

Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-53-generic x86_64)
capybara-webkit (1.5.2)
capybara (2.4.4)
QMake version 3.0
Using Qt version 5.2.1 in /usr/lib/x86_64-linux-gnu
arielscherman commented 7 years ago

I run into the same issue. I am trying to setup circleci and I am using capybara webkit. I tried to setup the xvfb as some of you mentioned, with no luck:

This is my circleci.yml file:

machine:
  timezone:
    America/Los_Angeles
  ruby:
    version: 2.3.0
  services:
    - elasticsearch

test:
  override:
    - xvfb-run -a bundle exec rspec

Any ideas?

twalpole commented 7 years ago

Closing this due to age. If this is still an issue with latest releases please create a new issue with a way to replicate.