Stack overflow from infinite loop with bundler in 1.9-mode

Anders: I could not reproduce this with a quick attempt on master. Can you try to bisect this on the jruby-1_6 branch and see what commit caused it? Or provide a demo app that exhibits the problem? I still suspect this file is getting loaded twice, for whatever reason.

Marking as "cannot reproduce". Reopen if you can reproduce it with current JRuby (1.6.6.dev from http://ci.jruby.org/snapshots).

I'm still seeing this (or a very similar "stack level too deep" error) on 1.6.6 in 1.9-mode.

Seems to be the same issue discussed in Warbler's tracker here: https://github.com/jruby/warbler/issues/59

I believe I encountered the same bug with jruby-19mode on travis-ci. A ticket logging the problem and workaround (though just a band-aid) can be seen here:

https://github.com/travis-ci/travis-ci/issues/424

As Charles noted, it looks to be directly related to requiring bundler multiple times. The unfortunate part is that locally I do not encounter this error, but I was able to consistently reproduce on travis-ci.

Ok, I want to fix this, but I have no way to reproduce at the moment. Everyone who has seen this should post where they saw it and hopefully make an attempt to get us something we can use to reproduce.

It's such a pain when the bug can't be reproduced locally! =/

Does any information from the build failure help?

http://travis-ci.org/#!/yellow5/foreigner-matcher/jobs/704384

Ok, JRuby 1.6.7 is out...if you can still reproduce this, we'll sit down in IRC and work through it.

I still cannot reproduce locally, but I can consistently get it happen on travis...

http://travis-ci.org/#!/yellow5/foreigner-matcher/jobs/732671

I tried dumping out the JRUBY_OPTS in the rake task in the hopes that replicating it would allow me to reproduce. I would be happy to ask them more about their environment for jruby-19mode.

Btw, I use the handle yellow5 on IRC and twitter if you would prefer to carry this on outside of jira.

Travis maintainers suggested I try using their Ruby VM with vagrant.

After launching it and following the setup steps in the previously posted travis job, I am still not able to reproduce! Since the job used jruby-1.6.6 and the VM installed jruby-1.6.7, I manually installed jruby-1.6.6 and tried it with no changes in behavior.

Since I can only reproduce it with a travis job, I think it's safe to close the ticket. I am willing to throw anything in a branch to try and expose information about the environment that could aid in reproduction, but I am sure you have bigger fish to fry. =)

Thanks for everything you and your team do!

JRuby 1.6.7 didn't fix this for me, but upgrading to Warbler 1.3.4 did.

Not sure what's changed in Warbler, but it works.

I'm glad this one is reported I've been seeing this very same bug with jruby-rack and recently even with warbler while running specs in --1.9 mode (ever since 1.6.5).
Sadly like reported in previous comments, it's hard to reproduce - but I was able to reproduce the behavior pretty deterministically setting up a local Travis worker using Vagrant.

It is definitely Gem::Specification related but other than that I was not able to track it down.
Here's a workaround I did for jruby-rack https://github.com/jruby/jruby-rack/commit/b0e32eb7755eff17fe40c0386878aa11751724f9
Prior to this it was always a "stack level too deep" with --1.9 e.g. http://travis-ci.org/#!/jruby/jruby-rack/builds/623363

Similar issue exists with warbler builds on Travis (thus jruby-1.9mode is currently disabled) ...
I was getting warbler to run the specs with jruby in --1.9 as well last week and hit it http://travis-ci.org/#!/kares/warbler/jobs/829158
Which does seem to involve spec code in add_bundler_gems https://github.com/jruby/warbler/blob/master/lib/warbler/traits/bundler.rb#L30

I think this got fixed by Warbler fixes at some point. If that's not the case and JRuby master or 1.6.7 still fail, reopen and describe how to reproduce.

Hey Charlie, as noted previously this is not an issue related to warbler it is "reproducable" with jruby-rack and we've seen it ever since 1.6.6 got released.

The tricky thing is we can only reproduce this in ENV['TRAVIS'] I'm not sure why but somehow `spec.cache_file` blows (in --1.9).
Thus it really seems as a JRuby 1.9 "regression" since 1.6.5.

Latest failure by turning off the work-around http://travis-ci.org/#!/kares/jruby-rack/jobs/1364882. It happens somewhere here https://github.com/kares/jruby-rack/blob/845a565146390d3620d47cf9280b1e574fad792c/Rakefile#L71-73

As for reproducing it, I've tried previously but have not been able to isolate it locally, but than it's not that hard to setup a local Travis worker with Vagrant + VirtualBox and you can reproduce it by running the jruby-rack specs there in 1.9 mode if you disable the "work-around" https://github.com/kares/jruby-rack/commit/845a565146390d3620d47cf9280b1e574fad792c

Sorry I could not be of more help here ...

Karol: Ok, thank you for confirming that it's still an issue. We'll get it fixed during the 1.7 cycle. 1.7 preview 1 will be out next week and not have a fix, but we'll definitely do it before 1.7 final.

I've just hit this issue myself. It was failing for me when running jruby 1.6.4 - 1.7 preview 1, and jruby -S rails server.

As soon as I fired up the browser, I saw:

Completed 500 Internal Server Error in 36ms

SystemStackError (stack level too deep):

Rendered c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/actionpack-3.1.0/lib/action_dispatch/middleware/templates/rescues/_trace.erb (5.0ms)
Rendered c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/actionpack-3.1.0/lib/action_dispatch/middleware/templates/rescues/_request_and_response.erb (6.0ms)
Rendered c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/actionpack-3.1.0/lib/action_dispatch/middleware/templates/rescues/diagnostics.erb within rescues/layout (20.0ms)

As soon as I tried the console however, I saw that whilst my Postgres database existed, and the service was running, the tables hadn't been migrated:

$ jruby -S rails console
Loading development environment (Rails 3.1.0)
irb(main):001:0> User.first
ActiveRecord::JDBCError: Table users does not exist
from arjdbc/jdbc/RubyJdbcConnection.java:121:in `columns'
from c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/activerecord-jdbc-adapter-1.2.0/lib/arjdbc/postgresql/adapter.rb:306:in `pg_columns'
from c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:95:in `initialize'
from c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:185:in `with_connection'
from c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:92:in `initialize'
from org/jruby/RubyProc.java:274:in `call'
from org/jruby/RubyProc.java:229:in `call'
from org/jruby/RubyHash.java:647:in `default'
from org/jruby/RubyHash.java:996:in `[]'
from c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:106:in `initialize'
from org/jruby/RubyProc.java:274:in `call'
from org/jruby/RubyProc.java:229:in `call'
from org/jruby/RubyHash.java:647:in `default'
from org/jruby/RubyHash.java:996:in `[]'
from c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/activerecord-3.1.0/lib/active_record/base.rb:711:in `columns_hash'
from c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/activerecord-3.1.0/lib/active_record/locking/optimistic.rb:145:in `locking_enabled?'
... 5 levels...
from (irb):1:in `evaluate'
from org/jruby/RubyKernel.java:1088:in `eval'
from c:/jruby-1.6.4/lib/ruby/1.8/irb.rb:158:in `eval_input'
from c:/jruby-1.6.4/lib/ruby/1.8/irb.rb:271:in `signal_status'
from c:/jruby-1.6.4/lib/ruby/1.8/irb.rb:155:in `eval_input'
from org/jruby/RubyKernel.java:1419:in `loop'
from org/jruby/RubyKernel.java:1191:in `catch'
from c:/jruby-1.6.4/lib/ruby/1.8/irb.rb:154:in `eval_input'
from c:/jruby-1.6.4/lib/ruby/1.8/irb.rb:71:in `start'
from org/jruby/RubyKernel.java:1191:in `catch'
from c:/jruby-1.6.4/lib/ruby/1.8/irb.rb:70:in `start'
from c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/railties-3.1.0/lib/rails/commands/console.rb:45:in `start'
from c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/railties-3.1.0/lib/rails/commands/console.rb:8:in `start'
from c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/railties-3.1.0/lib/rails/commands.rb:40:in `(root)'
from org/jruby/RubyKernel.java:1038:in `require'
from script/rails:6:in `(root)'irb(main):002:0>

Migration fixed this issue and then no more SystemStackError when I returned to server testing.

Investigating.

I forked warbler and enabled JRuby 1.9 mode on travis. No failure! http://travis-ci.org/#!/headius/warbler/builds/2025836

Continuing...will try jruby-head next, which is in 1.9 mode by default.

Attempt number 2...build number 3 against jruby-head, also in 1.9 mode. Also passed... http://travis-ci.org/#!/headius/warbler/builds/2025859

Moving on to jruby-rack.

I disabled the ENV['TRAVIS'] workaround in my fork of jruby-rack, pushed it, and the travis build succeeded in 1.8 and 1.9 modes: http://travis-ci.org/#!/headius/jruby-rack/builds/2025895

Is this getting spooky yet?

I'm starting to wonder if this was a temporary glitch...something wrong in Travis or Bundler or something else.

Is anyone able to reproduce this today with a repository I can fork?

tried myself with jruby-rack as well - can't seem to reproduce this anymore either.
hopefully it will last, as it now seems it was a Travis-CI issue after all ...
thanks for looking into this.

Marking as Cannot Reproduce since the two reproductions that worked before no longer seem to exhibit the problem. Hopefully this one is actually gone for good.

FYI, there have been other reports of stack overflow in Bundler that are not bug or environment-related but due to Bundler simply using a lot of stack. Those should be reported elsewhere (and already have been in most cases).