Hi Ola, I think I just saw that kind of java.lang.ArrayIndexOutOfBoundsException in compiled code too. That was using Rails. It was inconsistent: happening some times but not always for the same request (but once it happen my Rails server would never handle any new request). I'll attach my stacktrace if I can get it back. Still, I tried to roll back the SVN as far as rev #6293 and the bug was still there for me. Then I released I was actually doing some ActiveRecord manipulation in a background thread while possibly getting new requests on the same JRuby runtime. So I disabled that background stuff and made it happen in the same thread instead. Then I didn't see the bug anymore. I didn't even dare call it a bug as ActiveRecord isn't supposed to be threadsafe and at least I wasn't really sure it should work.
OK, not 100% it's the same bug but really looks the same. I'll try to get it back. Good luck, Raphaël Valyi. On Fri, Mar 28, 2008 at 4:35 PM, Ola Bini <[EMAIL PROTECTED]> wrote: > Hey > > I've run into some seriously strange. Now, first of all this problem is > actually a bad handling of a "stack level to deep" problem, combined > with ActiveSupport. > > Now, in a specific combination, running Expectations with ActiveSupport, > just loading them - will actually case MRI to get "stack level to deep". > Now, we get that too, sometimes. Specifically, when using -X-C we get it > correctly - when usinx -X+C I get an extremely long stack trace of > synthetic method invocations instead. > But sometimes I get this instead: > > java.lang.ArrayIndexOutOfBoundsException: 4 > at > > org.jruby.runtime.scope.ManyVarsDynamicScope.getValueDepthZeroOrNil(ManyVarsDynamicScope.java:93) > at > > org.jruby.runtime.scope.ManyVarsDynamicScope.getValueOrNil(ManyVarsDynamicScope.java:83) > at > > org.jruby.runtime.scope.OneVarDynamicScope.getValueOrNil(OneVarDynamicScope.java:75) > at > > ruby.jit.ruby.Users.olabini.workspace.jtestr_git.src.ruby.activesupport.lib.active_support.dependencies.new_constants_in13155965_9177946.closure_377_10(/Users/olabini/workspace/jtestr_git/src/ruby/activesupport/lib/active_support/dependencies.rb:379) > at > > ruby.jit.ruby.Users.olabini.workspace.jtestr_git.src.ruby.activesupport.lib.active_support.dependencies.new_constants_in13155965_9177946BlockCallback$closure_377_10xx1.call(Unknown > Source) > > This is a actually a quite funny error. When I looked at the source line > specified here (and notice that ActiveSupport dependencies actually wrap > _all_ require's in a new_constants_in block). The relevant part of > new_constants_in look like this: > > ensure > # Remove the stack frames that we added. > if defined?(watch_frames) && ! watch_frames.empty? > frame_ids = watch_frames.collect(&:object_id) > constant_watch_stack.delete_if do |watch_frame| > frame_ids.include? watch_frame.object_id > end > end > > Now, I don't know exactly what happens here. One possibility is that > frame_ids gets created dynamically, but the gets the wrong index for > some reason, lots of block vars have not been defined, that should have > been defined. What do you think? Of course, it's invalid anyway, but it > would be nice not see an ArrayIndexOutOfBoundsException for it. > > It's a bit of a pain to replicate reliably, though. I have a script that > does it by loading some other libraries and Expectations. What's funny > is that I have a comment in that script - if I remove the comment, this > problem doesn't happen - then I just get the regular stack level problem. > > Cheers > -- > Ola Bini (http://ola-bini.blogspot.com) > JRuby Core Developer > Developer, ThoughtWorks Studios (http://studios.thoughtworks.com) > Practical JRuby on Rails (http://apress.com/book/view/9781590598818) > > "Yields falsehood when quined" yields falsehood when quined. > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
