Forum: JRuby JRuby error coming from RubyRegexp.java inside of Rails method

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
22785d4dbf585723bf60458ece0170e1?d=identicon&s=25 Joseph Athman (Guest)
on 2009-05-26 16:40
(Received via mailing list)
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)|#]
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-05-26 18:34
(Received via mailing list)
Joseph Athman 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
22785d4dbf585723bf60458ece0170e1?d=identicon&s=25 Joseph Athman (Guest)
on 2009-05-26 18:58
(Received via mailing list)
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 Nutter <
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-05-26 20:10
(Received via mailing list)
Joseph Athman 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
22785d4dbf585723bf60458ece0170e1?d=identicon&s=25 Joseph Athman (Guest)
on 2009-05-26 22:09
(Received via mailing list)
>
> 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 Nutter <
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-05-26 23:40
(Received via mailing list)
Joseph Athman 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
This topic is locked and can not be replied to.