java.lang.ClassCastException: org.jruby.RubyNil cannot be cast to org.jruby.RubyMatchData #6640
Milestone
Comments
|
Can you get the full exception trace, preferably by passing |
|
Sure, please find below: |
|
If needed, I can attach the full code that creates the situation |
|
I have confirmed that this is indeed the same issue as #4868. We cannot avoid the threading issues with @gerases If you can provide a reproduction that would be great! I will need to be able to confirm my fix and write an appropriate test for it. |
|
@headius, you mean you would like me to provide the source code? It's no problem, just want to make sure I understand you correctly. |
|
Actually I think I have a small reproduction already: str = 'a,b,c,d,e'
Thread.abort_on_exception = true
p = proc { str.split(/,/) }
10.times.map { Thread.new { loop { p.call } } }.each(&:join)Which eventually yields: This will be fixed by #6644. String#split will still be writing to a shared location for $~ but it never reads from it so it will at least not conflict with its own usage. |
|
Cool, thank you very much!!! |
headius
added a commit
to headius/jruby
that referenced
this issue
Mar 31, 2021
See jruby#6640 for a failure that occurred in JRuby due to using the context backref slot as an "out" variable during regexp-based splitting.
|
@gerases Thank you for the bug report! |
2 tasks
headius
added a commit
to headius/jruby
that referenced
this issue
Apr 1, 2021
This changes all places we read the frame-local backref to use the thread-local match instead. None of these places used the backref for its content; they only used it to reuse the object, which is now handled more correctly by the thread-local match and the setBackRef method that marks matches as in-use. This should eliminate all internal data races against the $~ variable, since no core methods depend upon its value. This does not make $~ thread-safe but it pushes the issue to the edge, where the user will have to decide to use it knowing it may be updated across threads. See jruby#4868 for the original issue that this partially fixes, and see jruby#6640 for an issue caused by these internal data races.
headius
added a commit
to headius/jruby
that referenced
this issue
Apr 1, 2021
This changes all places we read the frame-local backref to use the thread-local match instead. None of these places used the backref for its content; they only used it to reuse the object, which is now handled more correctly by the thread-local match and the setBackRef method that marks matches as in-use. This should eliminate all internal data races against the $~ variable, since no core methods depend upon its value. This does not make $~ thread-safe but it pushes the issue to the edge, where the user will have to decide to use it knowing it may be updated across threads. See jruby#4868 for the original issue that this partially fixes, and see jruby#6640 for an issue caused by these internal data races.
eregon
pushed a commit
to ruby/spec
that referenced
this issue
Jun 2, 2021
See jruby/jruby#6640 for a failure that occurred in JRuby due to using the context backref slot as an "out" variable during regexp-based splitting.
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment Information
Jruby version: jruby 9.2.17.0 (2.5.8) 2021-03-29 84d363d OpenJDK 64-Bit Server VM 25.282-b08 on 1.8.0_282-b08 +jit [linux-x86_64]
Operating system: Linux 9738431d2f6d 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64 GNU/Linux
Expected Behavior
The skeleton code is:
When running that code under jruby, I expect the code to finish without exceptions
Actual Behavior
When running the above code under jruby, I get the following exception:
There are two things that fix the problem:
splitThe text was updated successfully, but these errors were encountered: