Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Cannot Reproduce
    • Affects Version/s: JRuby 1.6.5
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      RVM 1.9.2, bundler 1.0.21, OS X Lion
    • Number of attachments :
      0

      Description

      Hi!
      When I start rake in my Rails app with JRuby 1.6.5 with --1.9 it breaks with "stack level too deep". Using -d gives screen after screen of this:

      ...
      at org.jruby.internal.runtime.methods.AliasMethod.call(AliasMethod.java:56)
      at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:133)
      at rubyjit.full_gem_path_C6832BBF145F5FC75E71C0F1D212B0B02F354F9E._file_(/Users/anders.bengtsson/.rvm/gems/jruby-1.6.5/gems/bundler-1.0.21/lib/bundler/rubygems_ext.rb:21)
      at rubyjit.full_gem_path_C6832BBF145F5FC75E71C0F1D212B0B02F354F9E._file_(/Users/anders.bengtsson/.rvm/gems/jruby-1.6.5/gems/bundler-1.0.21/lib/bundler/rubygems_ext.rb)
      at org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:127)
      at org.jruby.internal.runtime.methods.AliasMethod.call(AliasMethod.java:56)
      at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:133)
      at rubyjit.full_gem_path_C6832BBF145F5FC75E71C0F1D212B0B02F354F9E._file_(/Users/anders.bengtsson/.rvm/gems/jruby-1.6.5/gems/bundler-1.0.21/lib/bundler/rubygems_ext.rb:21)
      at rubyjit.full_gem_path_C6832BBF145F5FC75E71C0F1D212B0B02F354F9E._file_(/Users/anders.bengtsson/.rvm/gems/jruby-1.6.5/gems/bundler-1.0.21/lib/bundler/rubygems_ext.rb)
      at org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:127)
      at org.jruby.internal.runtime.methods.AliasMethod.call(AliasMethod.java:56)
      at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:133)
      at rubyjit.full_gem_path_C6832BBF145F5FC75E71C0F1D212B0B02F354F9E._file_(/Users/anders.bengtsson/.rvm/gems/jruby-1.6.5/gems/bundler-1.0.21/lib/bundler/rubygems_ext.rb:21)
      at rubyjit.full_gem_path_C6832BBF145F5FC75E71C0F1D212B0B02F354F9E._file_(/Users/anders.bengtsson/.rvm/gems/jruby-1.6.5/gems/bundler-1.0.21/lib/bundler/rubygems_ext.rb)
      at org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:127)
      at org.jruby.internal.runtime.methods.AliasMethod.call(AliasMethod.java:56)
      Exception `SystemStackError' at org/jruby/RubyArray.java:1612 - stack level too deep

      The code in bundler it gets stuck in looks like this:

      alias_method :rg_full_gem_path, :full_gem_path
      alias_method :rg_loaded_from, :loaded_from

      def full_gem_path
      source.respond_to?(:path) ?
      Pathname.new(loaded_from).dirname.expand_path(Bundler.root).to_s :
      rg_full_gem_path
      end

      This doesn't happen with JRuby 1.6.4 (nor with 1.6.5 in 1.8-mode as far as I can tell).

        Activity

        Hide
        Charles Oliver Nutter added a comment -

        I feel like I've seen this before. The usual cause of this would be that the bundler RubyGems ext is getting loaded twice, so it re-aliases that name to itself on a second run-through. I need to find a way to reproduce this.

        Show
        Charles Oliver Nutter added a comment - I feel like I've seen this before. The usual cause of this would be that the bundler RubyGems ext is getting loaded twice, so it re-aliases that name to itself on a second run-through. I need to find a way to reproduce this.
        Hide
        Charles Oliver Nutter added a comment -

        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.

        Show
        Charles Oliver Nutter added a comment - 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.
        Hide
        Charles Oliver Nutter added a comment -

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

        Show
        Charles Oliver Nutter added a comment - Marking as "cannot reproduce". Reopen if you can reproduce it with current JRuby (1.6.6.dev from http://ci.jruby.org/snapshots ).
        Hide
        Anders Bengtsson added a comment -

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

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

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

        Show
        Anders Bengtsson added a comment - Seems to be the same issue discussed in Warbler's tracker here: https://github.com/jruby/warbler/issues/59
        Hide
        Cameron Dykes added a comment - - edited

        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.

        Show
        Cameron Dykes added a comment - - edited 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.
        Hide
        Charles Oliver Nutter added a comment -

        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.

        Show
        Charles Oliver Nutter added a comment - 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.
        Hide
        Cameron Dykes added a comment -

        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

        Show
        Cameron Dykes added a comment - 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
        Hide
        Charles Oliver Nutter added a comment -

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

        Show
        Charles Oliver Nutter added a comment - Ok, JRuby 1.6.7 is out...if you can still reproduce this, we'll sit down in IRC and work through it.
        Hide
        Cameron Dykes added a comment -

        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.

        Show
        Cameron Dykes added a comment - 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.
        Hide
        Cameron Dykes added a comment -

        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!

        Show
        Cameron Dykes added a comment - 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!
        Hide
        Anders Bengtsson added a comment -

        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.

        Show
        Anders Bengtsson added a comment - 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.
        Hide
        Karol Bucek added a comment -

        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

        Show
        Karol Bucek added a comment - 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
        Hide
        Charles Oliver Nutter added a comment -

        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.

        Show
        Charles Oliver Nutter added a comment - 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.
        Hide
        Karol Bucek added a comment -

        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 ...

        Show
        Karol Bucek added a comment - 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 ...
        Hide
        Charles Oliver Nutter added a comment -

        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.

        Show
        Charles Oliver Nutter added a comment - 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.
        Hide
        Simon Peter Nicholls added a comment -

        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.

        Show
        Simon Peter Nicholls added a comment - 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.
        Hide
        Charles Oliver Nutter added a comment -

        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.

        Show
        Charles Oliver Nutter added a comment - 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.
        Hide
        Charles Oliver Nutter added a comment -

        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.

        Show
        Charles Oliver Nutter added a comment - 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.
        Hide
        Charles Oliver Nutter added a comment -

        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?

        Show
        Charles Oliver Nutter added a comment - 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?
        Hide
        Karol Bucek added a comment -

        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.

        Show
        Karol Bucek added a comment - 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.
        Hide
        Charles Oliver Nutter added a comment -

        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).

        Show
        Charles Oliver Nutter added a comment - 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).

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Anders Bengtsson
          • Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: