We have recently installed a copy of our framework on another machine, and for some reason we get an error when using 'puts' instead of 'Kernel.puts' (we use Ruby)
This isn't a huge issue, but we occasionally use 'puts' to write to the cucumber results file.
This onlyhappens on 1 machine, not the other. Both are mac minis, same specs.
Both machines have the same gemlist, the same version of Ruby etc (they were both installed almost simultaneously).
Anyone else seen this?
Log:
2015-06-30 14:44:59 +0100 OUT: Error: undefined method <<' for nil:NilClass 2015-06-30 14:44:59 +0100 OUT: /Library/Ruby/Gems/2.0.0/gems/gherkin-2.12.2/lib/gherkin/formatter/json_formatter.rb:89:inwrite'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/formatter/gherkin_formatter_adapter.rb:166:in puts' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:181:inblock in send_to_all'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:179:in each' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:179:insend_to_all'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:173:in broadcast' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:154:inputs'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime/user_interface.rb:14:in puts' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/rb_support/rb_world.rb:107:inputs'
/Users/jenkins/workspace/TEST-regression-test_trial_mini/automation/ios/features/support/hooks.rb:104:in block in <top (required)>' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/core_ext/instance_exec.rb:48:ininstance_exec'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/core_ext/instance_exec.rb:48:in block in cucumber_instance_exec' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/core_ext/instance_exec.rb:69:incucumber_run_with_backtrace_filtering'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/core_ext/instance_exec.rb:36:in cucumber_instance_exec' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/rb_support/rb_hook.rb:14:ininvoke'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:114:in invoke' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:102:inblock in execute_before'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:101:in each' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:101:inexecute_before'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:15:in before' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:112:inblock in fire_hook'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:111:in each' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:111:infire_hook'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:107:in before' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:98:inbefore_and_after'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:82:in block in with_hooks' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:120:incall'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:120:in block (3 levels) in around' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:9:inblock in around'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:97:in call' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:97:inexecute_around'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/language_support/language_methods.rb:8:in around' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:119:inblock (2 levels) in around'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:123:in call' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime/support_code.rb:123:inaround'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:94:in around' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:81:inwith_hooks'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:13:in execute' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/scenario.rb:32:inblock in accept'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/scenario.rb:79:in with_visitor' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/scenario.rb:31:inaccept'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:58:in block in visit_feature_element' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:170:inbroadcast'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:57:in visit_feature_element' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/feature.rb:38:inblock in accept'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/feature.rb:37:in each' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/feature.rb:37:inaccept'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:27:in block in visit_feature' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:170:inbroadcast'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:26:in visit_feature' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/features.rb:28:inblock in accept'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/features.rb:17:in each' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/features.rb:17:ineach'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/features.rb:27:in accept' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:21:inblock in visit_features'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:170:in broadcast' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/ast/tree_walker.rb:20:invisit_features'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/runtime.rb:49:in run!' /Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/lib/cucumber/cli/main.rb:47:inexecute!'
/Library/Ruby/Gems/2.0.0/gems/cucumber-1.3.18/bin/cucumber:13:in <top (required)>' /usr/bin/cucumber:23:inload'
/usr/bin/cucumber:23:in
Something somewhere is overriding your puts. You'll just have to find it. As an alternative, use warn. From Avdi Grimm's Exceptional Ruby:
puts leaves something to be desired as a failure reporting method, however. Because its output goes to $stdout, which is buffered by default, output may not be printed immediately, or it may come out in a surprising order
warn is more succinct, while still using $stderr as its output stream. Note also that the output of warn can be temporarily silenced by passing the -W0 flag to Ruby.
Related
I'm writing an application to parse XML. I have to obtain data from one XML file, and then in a loop I have to open another XML file.
The code looks like this:
$doc = Nokogiri::XML(open('myxmladress'))
$doc.xpath('//job').each do |job|
if job.xpath('name').text.include?('joe')
$doc2 = Nokogiri::XML(open('myxmladress_for_joe'))
end
end
I believe that I cannot have multiple HTTP connections open.
Can I simply download the whole file instead of using
$doc Nokogiri::XML(open('myxmladress'))
or is there any way to close the Nokogiri HTTP connection?
What is more I'm downloading it by https.
My error:
in `open_http': 500 Server Error (OpenURI::HTTPError)
from /home/nagios/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/open-uri.rb:737:in `buffer_open'
from /home/nagios/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/open-uri.rb:212:in `block in open_loop'
from /home/nagios/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/open-uri.rb:210:in `catch'
from /home/nagios/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/open-uri.rb:210:in `open_loop'
from /home/nagios/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/open-uri.rb:151:in `open_uri'
from /home/nagios/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/open-uri.rb:717:in `open'
from /home/nagios/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/open-uri.rb:35:in `open'
from jenkins_auth.rb:97:in `block (2 levels) in combine_partial_results'
from /home/nagios/.rvm/gems/ruby-2.3.0/gems/nokogiri-1.6.7.2/lib/nokogiri/xml/node_set.rb:187:in `block in each'
from /home/nagios/.rvm/gems/ruby-2.3.0/gems/nokogiri-1.6.7.2/lib/nokogiri/xml/node_set.rb:186:in `upto'
from /home/nagios/.rvm/gems/ruby-2.3.0/gems/nokogiri-1.6.7.2/lib/nokogiri/xml/node_set.rb:186:in `each'
from jenkins_auth.rb:89:in `block in combine_partial_results'
from /home/nagios/.rvm/gems/ruby-2.3.0/gems/nokogiri-1.6.7.2/lib/nokogiri/xml/node_set.rb:187:in `block in each'
from /home/nagios/.rvm/gems/ruby-2.3.0/gems/nokogiri-1.6.7.2/lib/nokogiri/xml/node_set.rb:186:in `upto'
from /home/nagios/.rvm/gems/ruby-2.3.0/gems/nokogiri-1.6.7.2/lib/nokogiri/xml/node_set.rb:186:in `each'
from jenkins_auth.rb:86:in `combine_partial_results'
from jenkins_auth.rb:130:in `get_tests_for_job'
from jenkins_auth.rb:137:in `<main>'
You are using OpenUri to fetch a document from a URL. I am pretty sure that this doesn't leave any open connection, but reads the document into an IO like object, kind of like a file.
Your problem seems to be that the server has had an internal error.
I am using the open source repo for the OSS Cloud Foundry Liberty Profile Buildpack and running into the following failures when executing bundle exec rspec
681 examples, 3 failures
Failed examples:
rspec ./spec/bin/compile_spec.rb:49 # compile script should work with the liberty WEB-INF case
rspec ./spec/bin/compile_spec.rb:65 # compile script should also work with the zipped up server case
rspec ./spec/bin/compile_spec.rb:82 # compile script pass environment variable directory
The 3 failures have a common stack ...
1) compile script should work with the liberty WEB-INF case
Failure/Error: expect(result).to be_success
expected `#<Process::Status: pid 84398 exit 1>.success?` to return true, got false
# ./vendor/bundle/ruby/1.9.1/gems/rspec-expectations-3.0.4/lib/rspec/expectations/fail_with.rb:30:in `fail_with'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-expectations-3.0.4/lib/rspec/expectations/handler.rb:37:in `handle_failure'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-expectations-3.0.4/lib/rspec/expectations/handler.rb:48:in `handle_matcher'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-expectations-3.0.4/lib/rspec/expectations/expectation_target.rb:54:in `to'
# ./spec/bin/compile_spec.rb:59:in `block (5 levels) in <top (required)>'
# /Users/kelapr/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/open3.rb:208:in `popen_run'
# /Users/kelapr/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/open3.rb:90:in `popen3'
# ./spec/bin/compile_spec.rb:53:in `block (4 levels) in <top (required)>'
# ./spec/bin/compile_spec.rb:124:in `with_memory_limit'
# ./spec/bin/compile_spec.rb:52:in `block (3 levels) in <top (required)>'
# /Users/kelapr/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/tmpdir.rb:83:in `mktmpdir'
# ./spec/bin/compile_spec.rb:50:in `block (2 levels) in <top (required)>'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/example.rb:148:in `instance_exec'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/example.rb:148:in `block in run'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/example.rb:301:in `with_around_example_hooks'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/example.rb:145:in `run'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/example_group.rb:494:in `block in run_examples'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/example_group.rb:490:in `map'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/example_group.rb:490:in `run_examples'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/example_group.rb:457:in `run'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/runner.rb:112:in `block (2 levels) in run_specs'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/runner.rb:112:in `map'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/runner.rb:112:in `block in run_specs'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/reporter.rb:54:in `report'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/runner.rb:108:in `run_specs'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/runner.rb:86:in `run'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/runner.rb:70:in `run'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/lib/rspec/core/runner.rb:38:in `invoke'
# ./vendor/bundle/ruby/1.9.1/gems/rspec-core-3.0.4/exe/rspec:4:in `<top (required)>'
# ./vendor/bundle/ruby/1.9.1/bin/rspec:23:in `load'
# ./vendor/bundle/ruby/1.9.1/bin/rspec:23:in `<main>'
Cans someone guide us on how to resolve these failures that seem to stem from an Open3.popen3 call from within a Dir.mktmpdir block. These results from the master branch of https://github.com/cloudfoundry/ibm-websphere-liberty-buildpack/
-Thanks.
I don't see such failures in the Travis CI system. Also, testing on a local machine didn't result in any failures. Do you see any other errors in the test output? In case of a failure, there should be messages starting with stdout: and stderr: in the output.
The issues with the long running tests with these failure is that stack traces are very poor at figuring out what actually happened. We determined the root cause of these failures as lack of network connectivty.
I am completely new to Ruby so my question may have quite a simple answer. However, I couldn't find an answer on stackoverflow.
I have the following very simple Sinatra app:
# myapp.rb
require 'rubygems'
require 'sinatra'
require 'json'
range=(199..2000).step(1)
set :port, 8888
get '/hostname' do
content_type :json
return range.next.to_json
end
Sinatra is starting:
ruby testsinatra.rb
== Sinatra/1.0 has taken the stage on 8888 for development with backup from WEBrick
[2014-09-11 08:43:18] INFO WEBrick 1.3.1
[2014-09-11 08:43:18] INFO ruby 1.8.7 (2011-06-30) [x86_64-linux]
[2014-09-11 08:43:18] INFO WEBrick::HTTPServer#start: pid=8215 port=8888
and serving first request:
curl -ks http://localhost:8888/hostname
199
but failing with an error at the second request:
RuntimeError - continuation called across threads:
/usr/lib/ruby/1.8/generator.rb:131:in `call'
/usr/lib/ruby/1.8/generator.rb:131:in `next'
/usr/lib/ruby/1.8/generator.rb:189:in `next'
testsinatra.rb:30:in `GET /hostname'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:863:in `call'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:863:in `route'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:521:in `instance_eval'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:521:in `route_eval'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:500:in `route!'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:497:in `catch'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:497:in `route!'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:476:in `each'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:476:in `route!'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:601:in `dispatch!'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:411:in `call!'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `instance_eval'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `invoke'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `catch'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `invoke'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:411:in `call!'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:399:in `call'
/usr/lib/ruby/gems/1.8/gems/rack-1.5.2/lib/rack/showexceptions.rb:24:in `call'
/usr/lib/ruby/gems/1.8/gems/rack-1.5.2/lib/rack/methodoverride.rb:21:in `call'
/usr/lib/ruby/gems/1.8/gems/rack-1.5.2/lib/rack/commonlogger.rb:33:in `call'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:979:in `call'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:1003:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:1003:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:979:in `call'
/usr/lib/ruby/gems/1.8/gems/rack-1.5.2/lib/rack/handler/webrick.rb:60:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
/usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
/usr/lib/ruby/gems/1.8/gems/rack-1.5.2/lib/rack/handler/webrick.rb:14:in `run'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:946:in `run!'
/usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/main.rb:25
testsinatra.rb:27
Clearly, I'm missing something basic. Please advice.
Testing the code gives:
FiberError at /hostname
fiber called across threads
You can find a related question here: Sharing an enumerator across threads . It seems that the Fiber code stores the ID of the first thread that made an access to the object, and immediately fails when another thread tries to do so. You apparently just can't share enumerators between threads, and must resort to different means.
Please also note that global variables might be accessed simultaneously by different threads and you should always use thread-safe objects or explicit locking.
I'm new to ruby and currently having issues deploying with capistrano. below the errors I am getting.
cap aborted!
Operation timed out - connect(2)
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/net-ssh-2.7.0/lib/net/ssh/transport/session.rb:67:in `initialize'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/net-ssh-2.7.0/lib/net/ssh/transport/session.rb:67:in `open'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/net-ssh-2.7.0/lib/net/ssh/transport/session.rb:67:in `block in initialize'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/net-ssh-2.7.0/lib/net/ssh/transport/session.rb:67:in `initialize'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/net-ssh-2.7.0/lib/net/ssh.rb:200:in `new'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/net-ssh-2.7.0/lib/net/ssh.rb:200:in `start'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/sshkit-1.0.0/lib/sshkit/backends/netssh.rb:156:in `ssh'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/sshkit-1.0.0/lib/sshkit/backends/netssh.rb:109:in `block in _execute'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/sshkit-1.0.0/lib/sshkit/backends/netssh.rb:106:in `tap'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/sshkit-1.0.0/lib/sshkit/backends/netssh.rb:106:in `_execute'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/sshkit-1.0.0/lib/sshkit/backends/netssh.rb:54:in `execute'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/sshkit-1.0.0/lib/sshkit/backends/abstract.rb:75:in `within'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.0/lib/capistrano/tasks/git.rake:44:in `block (3 levels) in <top (required)>'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/sshkit-1.0.0/lib/sshkit/backends/netssh.rb:42:in `instance_exec'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/sshkit-1.0.0/lib/sshkit/backends/netssh.rb:42:in `run'
/Users/stefydu/.rvm/gems/ruby-2.0.0-p247/gems/sshkit-1.0.0/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute'
Tasks: TOP => git:create_release => git:update
(See full trace by running task with --trace)
Not a solution, but an explanation with workaround:
Capistrano 3, and with it sshkit, doesn't reuse existing SSH connections, but start a new one for every task (see https://github.com/capistrano/sshkit/issues/34).
Some servers, respectively their firewalls, seem to block new connection requests if they come to fast or if there are too many open connections.
Solutions:
Fix SSHKit/Capistrano to reuse connections
Configure your server/firewall to allow tons of parallel ssh sessions (for a simple rails app about 15)
use my hack below (Disclaimer: no, don't use it):
We're going to extend (monkeypatch) the execute method in gems/sshkit-1.1.0/lib/sshkit/backends/netssh.rb. That can be done via the Capfile:
# Overwrite execute method to avoid timeouts
class SSHKit::Backend::Netssh
def execute(*args)
_execute(*args).success?
rescue Errno::ETIMEDOUT
#tries ||= 0
raise "Nope, no way" if #tries > 5
puts "Timeout. yeah. Try it again (#{#tries})"
sleep 5
#tries += 1
execute(*args)
end
end
This gives the server a chance to breathe...
Capistrano uses a connection pool for SSH now:
https://github.com/capistrano/sshkit/pull/70
EDIT : (SOLVED) actually it probably was raised BECAUSE OF an infinite loop
I was coding and after adding a method I got this :
user_name#the_computer:/media/ECC3-C3B0/Prog/mts/src/mts$ rake test --trace
** Invoke test (first_time)
** Execute test
/home/user_name/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36: stack level too deep (SystemStackError)
rake aborted!
Command failed with status (1): [/home/user_name/.rvm/rubies/ruby-1.9.3-p19...]
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils.rb:53:in `block in create_shell_runner'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils.rb:45:in `call'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils.rb:45:in `sh'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:39:in `sh'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils.rb:82:in `ruby'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:39:in `ruby'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/testtask.rb:99:in `block (2 levels) in define'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:60:in `verbose'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/testtask.rb:98:in `block in define'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
/home/user_name/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block (2 levels) in top_level'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block in top_level'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `block in run'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/bin/rake:33:in `<top (required)>'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/bin/rake:19:in `load'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/bin/rake:19:in `<main>'
/home/user_name/.rvm/gems/ruby-1.9.3-p194/bin/ruby_noexec_wrapper:14:in `eval'
/home/user_name/.rvm/gems/ruby-1.9.3-p194/bin/ruby_noexec_wrapper:14:in `<main>'
Tasks: TOP => test
I'm pretty sure there is no infinite recursive loop involved.
The code is for now somehow gemified, but I also got the error running the ruby file directly.
Thank you for any help on how to (get some information to, run some tests to) fix the problem, if possible without having to rewrite the whole thing...
Environment :
ruby 1.9.3p194 / rails 3.2.8, installed via rvm
the program at this stage only uses rails string inflexions functions
OS : linux kubuntu i386
memory 4GO
'ulimit -s' : 8192 (stack size in kB)
What I tried unsuccessfully :
removed the chunk of code where the exception was initially raised, but it was still raised a tiny bit later at runtime
set stack size with command line 'ulimit -s 20000', 'ulimit -s unlimited'. Same error, apparently at the same place (which makes me think the stack size wasn't actually changed)
downgraded to ruby1.9.2 / rails3.1.3, got the same message
same error under Windows
Application context :
I'm writing an application that heavily uses ruby mixins.
Besides I created a bunch of classes that generate mixins (instance / class methods modules to be included by other classes).
So all in all I end up with quite a bit of generated named modules with some custom generated code, and classes with many ancestors.
But that should eventually save me quite a bit of pain in the as$ when I write the program that sits on top of this lib (that's the plan anyway).
Resources I used :
How to increase stack size for a ruby app. Recursive app getting: Stack level too deep (SystemStackError)
http://dalibornasevic.com/posts/5-ruby-stack-level-too-deep-systemstackerror
EDIT : Until some code is available for the showing/testing, let's abstract my question down to this one : Are there other cases that raise stack level too deep exception, besides the classical program-execution-tree-is-too-deep scenario (crossing fingers it's clear and means something...) ?
Are there other cases that raise stack level too deep exception, besides the classical program-execution-tree-is-too-deep scenario?
Yes. Since the stack is not measured in depth, but in bytes, anything stored on the stack will fill it up sooner:
def recurse(depth=0)
recurse depth+1
rescue SystemStackError
depth
end
=> nil
recurse
=> 8717
def recurse(depth=0)
a,b,c = 1,2,3
recurse depth+1
rescue SystemStackError
depth
end
=> nil
recurse
=> 7264
def recurse(depth=0)
a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z = *(0..25)
recurse depth+1
rescue SystemStackError
depth
end
=> nil
recurse
=> 3187
In this example, a function with only one variable can go several thousand calls deep before failing, and adding three more variables does very little; but adding 26 more variables balloons the stack size to a point where only around 3000 levels are available.
This will, of course depend somewhat on the ruby implementation, and the system it's running on. But I believe it will always hold as a general rule.
However, I still think recursion is likely your problem, since the number of variables required to have this happen at small call chain lengths is immense.