JRuby error coming from RubyRegexp.java inside of Rails method

Ruby JRuby
1

Background: we are using JRuby 1.3 RC1 with Rails 2.3.2 and the
Glassfish
gem. We are running Rails in threadsafe mode and have a couple other
background threads constantly running which pretty heavily use XML
serialization. We had one of these background threads completely die
with a
JRuby exception. From what I can see it looks like it took place while
we
were trying to serialize one of our AR models to XML. Here is the piece
of
Ruby code that died:

rails\activerecord\lib\active_record\connection_adapters\abstract\schema_definitions.rb

      # Doesn't handle time zones.
      def fast_string_to_time(string)
        if string =~ Format::ISO_DATETIME
          microsec = ($7.to_f * 1_000_000).to_i
          new_time $1.to_i, $2.to_i, $3.to_i, $4.to_i, $5.to_i,

$6.to_i,
microsec
end
end

Here is the JRuby exception we got. I’m just including the top of the
stacktrace, but I can send the whole one out if that helps. Any ideas
as to
what could have caused this or what we can do to prevent this in the
future?

java.lang.NullPointerException|#]
at org.jruby.RubyRegexp.nth_match(RubyRegexp.java:1751)|#]
at
ruby.jit.ruby.C_3a_.InstantRails_minus_2_dot_0_minus_win.instantrails2_dot_0.rails_apps.railpro.vendor.rails.activerecord.lib.active_record.connection_adapters.abstract.
schema_definitions.fast_string_to_time3070175_14139719.file(schema_definitions.rb:199)
|#]
at
org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:145)|#]
at
org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:154)|#]
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:115)|#]
at
ruby.jit.ruby.C_3a_.InstantRails_minus_2_dot_0_minus_win.instantrails2_dot_0.rails_apps.railpro.vendor.rails.activerecord.lib.active_record.connection_adapters.abstract.schema_definitions.string_to_time16813396_32596007.file(schema_definitions.rb:136)|#]
at
org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:145)|#]
at
org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:154)|#]
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:115)|#]
at
ruby.jit.ruby.C_3a_.InstantRails_minus_2_dot_0_minus_win.instantrails2_dot_0.rails_apps.railpro.vendor.rails.activerecord.lib.active_record.attribute_methods.created_at2542580_14139719.file(attribute_methods.rb:211)|#]
at
org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:128)|#]
at
org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:146)|#]
at org.jruby.RubyClass.finvoke(RubyClass.java:393)|#]
at org.jruby.RubyObject.send(RubyObject.java:1413)|#]
at
org.jruby.RubyObject$i_method_multi$RUBYINVOKER$send.call(org/jruby/RubyObject$i_method_multi$RUBYINVOKER$send.gen)|#]
at
org.jruby.internal.runtime.methods.JavaMethod$JavaMethodZeroOrOneOrNBlock.call(JavaMethod.java:259)|#]
at
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:278)|#]
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:117)|#]
at
ruby.jit.ruby.C_3a_.InstantRails_minus_2_dot_0_minus_win.instantrails2_dot_0.rails_apps.railpro.vendor.rails.activerecord.lib.active_record.serializers.xml_serializer.compute_value25687255_12207417.file(xml_serializer.rb:336)|#]
at
org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:111)|#]
at
org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:138)|#]
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:75)|#]
at
ruby.jit.ruby.C_3a_.InstantRails_minus_2_dot_0_minus_win.instantrails2_dot_0.rails_apps.railpro.vendor.rails.activerecord.lib.active_record.serializers.xml_serializer.initialize21385198_12207417.file(xml_serializer.rb:287)|#]
at
org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:196)|#]
at
org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:178)|#]
at
org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:164)|#]
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:171)|#]
at org.jruby.RubyClass$SpecificArityNew.call(RubyClass.java:621)|#]
at
org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:172)|#]
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:155)|#]
at
ruby.jit.ruby.C_3a_.InstantRails_minus_2_dot_0_minus_win.instantrails2_dot_0.rails_apps.railpro.vendor.rails.activerecord.lib.active_record.serializers.xml_serializer.serializable_attributes812351_14139719.block_0$RUBY$block(xml_serializer.rb:199)|#]
at
ruby.jit.ruby.C_3a_.InstantRails_minus_2_dot_0_minus_win.instantrails2_dot_0.rails_apps.railpro.vendor.rails.activerecord.lib.active_record.serializers.xml_serializer.serializable_attributes812351_14139719BlockCallback$block_0$RUBY$__block__xx1.call(Unknown
Source)|#]
at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:102)|#]
at org.jruby.runtime.Block.yield(Block.java:194)|#]

2

Joseph A. wrote:

Background: we are using JRuby 1.3 RC1 with Rails 2.3.2 and the
Glassfish gem. We are running Rails in threadsafe mode and have a
couple other background threads constantly running which pretty heavily
use XML serialization. We had one of these background threads
completely die with a JRuby exception. From what I can see it looks
like it took place while we were trying to serialize one of our AR
models to XML. Here is the piece of Ruby code that died:
…
Here is the JRuby exception we got. I’m just including the top of the
stacktrace, but I can send the whole one out if that helps. Any ideas
as to what could have caused this or what we can do to prevent this in
the future?

This is very likely one of two threading bugs I fixed for RC2, where
backrefs were getting either shared or reset to nil while other threads
accessed them. I’d recommend you try out a nightly or RC2 and see if the
problem goes away, because I’d bet it does.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
3

That sounds just like what our problem is. So do global variables like
$1
get shared across threads? This is the first time I’ve worked on a
multi-threaded Ruby app. The whole notion of global variables and
multiple
threads kind of blows my mind.

Has RC2 officially come out yet?

Joe

On Tue, May 26, 2009 at 11:33 AM, Charles Oliver N. <

4

I think we’ll be doing it today. If you want a nightly, which is pretty
close to RC2 now, check out http://jruby.headius.com:8080/hudson under the
“jruby-dist” build.

The site seems totally down for me. Are there any mirrors?

Joe

On Tue, May 26, 2009 at 1:09 PM, Charles Oliver N. <

5

Joseph A. wrote:

I think we'll be doing it today. If you want a nightly, which is
pretty close to RC2 now, check out
http://jruby.headius.com:8080/hudson under the "jruby-dist" build.

The site seems totally down for me. Are there any mirrors?

Oh, rats…I was going to reboot this weekend and forgot. I’ll get it up
tonight, and we’ll have RC2 tomorrow.

For now you could pull from github and build yourself, if you like.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
6

Joseph A. wrote:

That sounds just like what our problem is. So do global variables like
$1 get shared across threads? This is the first time I’ve worked on a
multi-threaded Ruby app. The whole notion of global variables and
multiple threads kind of blows my mind.

The backref-related variables ($1, $~, $` etc) and the lastline variable
($_) are local to a method body and should only be shared across threads
if a closure is called across threads. The errorinfo variable ($!) is
thread-local. Most other variables are “real” globals.

The bugs fixed recently include one that caused $~ (and all related
variables) to potentially see a nil value when $~ was being updated, and
another that resulted in $~ and $_ being shared across both calls and
threads when they should not be. Both are resolved now.

Has RC2 officially come out yet?

I think we’ll be doing it today. If you want a nightly, which is pretty
close to RC2 now, check out http://jruby.headius.com:8080/hudson under
the “jruby-dist” build.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email