JRuby

RegexpError: target of repeat operator is invalid

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: JRuby 1.1.2
  • Fix Version/s: JRuby 1.1.6
  • Component/s: Core Classes/Modules
  • Labels:
    None
  • Environment:
    jruby 1.1.2
  • Number of attachments :
    0

Description

Using autotest for an rspec based project when errors occur there is a Regexp that raises an error in Jruby while no error is raised in MRI.

ruby -e "/\n(\.\/)?(.*\.rb):[\d]+:\Z?/"

jruby -e "/\n(\.\/)?(.*\.rb):[\d]+:\Z?/"
-e:1: target of repeat operator is invalid: /\n(\.\/)?(.*\.rb):[\d]+:\Z?/ (RegexpError)

Rubinius has the same bug found here:
http://rubinius.lighthouseapp.com/projects/5089-rubinius/tickets/587-regexperror-target-of-repeat-operator-is-invalid

Backtrace:
/mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/rspec-1.1.4/lib/autotest/rspec.rb:30:in `consolidate_failures': target of repeat operator is invalid: /\n(\.\/)?(.*\.rb):[\d]+:\Z?/ (RegexpError)
from /mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/rspec-1.1.4/lib/autotest/rspec.rb:30:in `each'
from /mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/rspec-1.1.4/lib/autotest/rspec.rb:30:in `consolidate_failures'
from /mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/ZenTest-3.10.0/lib/autotest.rb:401:in `handle_results'
from /mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/ZenTest-3.10.0/lib/autotest.rb:274:in `run_tests'
from /mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/ZenTest-3.10.0/lib/autotest.rb:228:in `get_to_green'
from /mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/ZenTest-3.10.0/lib/autotest.rb:208:in `run'
from /mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/ZenTest-3.10.0/lib/autotest.rb:206:in `loop'
from /mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/ZenTest-3.10.0/lib/autotest.rb:206:in `run'
from /mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/ZenTest-3.10.0/lib/autotest.rb:136:in `run'
from /mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/ZenTest-3.10.0/bin/autotest:55:in `/mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/ZenTest-3.10.0/bin/autotest'
from /mnt/intex/jruby/jruby-1.1.2/lib/ruby/gems/1.8/gems/ZenTest-3.10.0/bin/autotest:19:in `load'
from /mnt/intex/jruby/jruby-1.1.2/bin/autotest:19

Activity

Hide
Charles Oliver Nutter added a comment -

I think this has come up before and it may be an Oniguruma/Joni bug. Rubinius and Ruby 1.9 use Oniguruma, and both show the issue.

Show
Charles Oliver Nutter added a comment - I think this has come up before and it may be an Oniguruma/Joni bug. Rubinius and Ruby 1.9 use Oniguruma, and both show the issue.
Hide
Brian Tatnall added a comment -

Yeah, I didn't check 1.9, but the same error in Rubinius had me guessing Joni. I searched and couldn't find the issue anywhere in JRuby's issues. Better to have it documented I guess.

Show
Brian Tatnall added a comment - Yeah, I didn't check 1.9, but the same error in Rubinius had me guessing Joni. I searched and couldn't find the issue anywhere in JRuby's issues. Better to have it documented I guess.
Hide
Charles Oliver Nutter added a comment -

Punting...not very critical, and it's an issue shared with Oniguruma. Downgrading to "major".

Show
Charles Oliver Nutter added a comment - Punting...not very critical, and it's an issue shared with Oniguruma. Downgrading to "major".
Hide
Marcin Mielzynski added a comment -

The issue is that Oniguruma treats quantifiers applied to anchors as invalid ones. This can be easily turned of, though, the problem is that e.g. \z+ has kind of undefined behavior (it differs among perl, ptyhon, ruby, etc).
The good news is that when this check is turned off Joni matches MRI successful matches in all weird cases (the only difference is the string index returned as a match).

"\n\n\na" =~ /a/ => 3
"\n\n\na" =~ /a\z?/ => 0

JRuby would return 3 in both cases.

Show
Marcin Mielzynski added a comment - The issue is that Oniguruma treats quantifiers applied to anchors as invalid ones. This can be easily turned of, though, the problem is that e.g. \z+ has kind of undefined behavior (it differs among perl, ptyhon, ruby, etc). The good news is that when this check is turned off Joni matches MRI successful matches in all weird cases (the only difference is the string index returned as a match).
"\n\n\na" =~ /a/ => 3
"\n\n\na" =~ /a\z?/ => 0
JRuby would return 3 in both cases.
Hide
Charles Oliver Nutter added a comment -

Marcin: Is this a behavior we could have turned off by default in 1.8 mode and turned on in 1.9 mode? That would eliminate it as an incompatibility for apps that are using \z.

Show
Charles Oliver Nutter added a comment - Marcin: Is this a behavior we could have turned off by default in 1.8 mode and turned on in 1.9 mode? That would eliminate it as an incompatibility for apps that are using \z.
Hide
Marcin Mielzynski added a comment -

There is absolutely no problem doing so (via flag in RubyInstanceConfig), though, I'd guess Oniguruma on it's own or Rubinius guys are going to match 1.8 anyways here (so 1.9 is more likely to match 1.8 imho).

Show
Marcin Mielzynski added a comment - There is absolutely no problem doing so (via flag in RubyInstanceConfig), though, I'd guess Oniguruma on it's own or Rubinius guys are going to match 1.8 anyways here (so 1.9 is more likely to match 1.8 imho).
Hide
Marcin Mielzynski added a comment -

More precisely: (1.9 is more likely going to match 1.8 imho).

Show
Marcin Mielzynski added a comment - More precisely: (1.9 is more likely going to match 1.8 imho).
Hide
Marcin Mielzynski added a comment -

Turned out to be true, 1.9 just got a fix that allows this. Applying the exact same fix to joni (only for non-vanilla mode).

Show
Marcin Mielzynski added a comment - Turned out to be true, 1.9 just got a fix that allows this. Applying the exact same fix to joni (only for non-vanilla mode).
Hide
Marcin Mielzynski added a comment -

Fixed in r8218-r8220. We'll match 1.9 on all edge cases.

Show
Marcin Mielzynski added a comment - Fixed in r8218-r8220. We'll match 1.9 on all edge cases.

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: