Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Open3 fails with ArrayStoreException after ~50 executions #2615

Closed
philr opened this issue Feb 23, 2015 · 4 comments
Closed

Open3 fails with ArrayStoreException after ~50 executions #2615

philr opened this issue Feb 23, 2015 · 4 comments
Labels
ir JRuby 9000
Milestone
JRuby 9.0.0.0.pre2

Comments

@philr
Copy link
Contributor

philr commented Feb 23, 2015

I am using jruby 9.0.0.0-SNAPSHOT (2.2.0p0) 2015-02-22 10fafff OpenJDK 64-Bit Server VM 24.75-b04 on 1.7.0_75-b13 +jit [linux-amd64].

I am finding that after about 50 process executions, Open3 fails with a java.lang.ArrayStoreException: org.jruby.runtime.Block.

This can be replicated by running:

jruby -ropen3 -e '100.times { Open3.capture3("jruby", "-v") }'

In the example, the exception is raised on about the 50th execution of the block (the exact execution where the failure occurs appears to vary slightly between test runs).

The exception stack trace is as follows:

ManyVarsDynamicScope.java:157:in `setValueOneDepthZero': java.lang.ArrayStoreException: org.jruby.runtime.Block
    from /home/philr/.rvm/rubies/jruby-head/lib/ruby/stdlib/open3.rb:83:in `__script__'
    from CompiledIRMethod.java:106:in `call'
    from InterpretedIRMethod.java:127:in `call'
    from WrapperMethod.java:90:in `call'
    from CachingCallSite.java:273:in `cacheAndCall'
    from CachingCallSite.java:79:in `callBlock'
    from CachingCallSite.java:83:in `call'
    from /home/philr/.rvm/rubies/jruby-head/lib/ruby/stdlib/open3.rb:-1:in `invokeOther16:popen3'
    from /home/philr/.rvm/rubies/jruby-head/lib/ruby/stdlib/open3.rb:252:in `__script__'
    from CompiledIRMethod.java:106:in `call'
    from CompiledIRMethod.java:150:in `call'
    from InterpretedIRMethod.java:232:in `call'
    from DynamicMethod.java:214:in `call'
    from WrapperMethod.java:62:in `call'
    from CachingCallSite.java:193:in `call'
    from -e:-1:in `invokeOther2:capture3'
    from -e:1:in `-e_CLOSURE_1__-e_0'
    from CompiledIRBlockBody.java:66:in `commonYieldPath'
    from IRBlockBody.java:84:in `yieldSpecific'
    from Block.java:116:in `yieldSpecific'
    from RubyFixnum.java:300:in `times'
    from RubyFixnum$INVOKER$i$0$0$times.gen:-1:in `call'
    from CachingCallSite.java:303:in `cacheAndCall'
    from CachingCallSite.java:141:in `callBlock'
    from CachingCallSite.java:145:in `call'
    from -e:-1:in `invokeOther5:times'
    from -e:1:in `__script__'
    from MethodHandle.java:599:in `invokeWithArguments'
    from Compiler.java:112:in `load'
    from Ruby.java:827:in `runScript'
    from Ruby.java:820:in `runScript'
    from Ruby.java:750:in `runNormally'
    from Ruby.java:572:in `runFromMain'
    from Main.java:404:in `doRunFromMain'
    from Main.java:299:in `internalRun'
    from Main.java:226:in `run'
    from Main.java:198:in `main'
@philr
Copy link
Contributor Author

philr commented Feb 23, 2015

Judging by build history on Travis CI, this issue started occurring somewhere between a10fccc and c804f97.

@enebo enebo added this to the 9.0.0.0.pre2 milestone Feb 23, 2015
@enebo
Copy link
Member

enebo commented Feb 23, 2015

@philr This is likely still fall out from our switch from always creating a Proc whether it is used or not or leaving it a raw block internally if we know it is not used in the current scope. You are seeing it 50 times because the JIT is compiling this and trying to store the value as an IRubyObject (normal Ruby object) when it is still a raw block. This is quite serious so we will fix for pre2.

@headius
Copy link
Member

headius commented Mar 12, 2015

This appears to be working with recent IR and JIT fixes. I was able to run your original example with 50-threshold JIT as well as 0-threshold JIT (compiled immediately, so all 100 iters should have hit this bug) and things worked fine.

@headius headius closed this as completed Mar 12, 2015
@philr
Copy link
Contributor Author

philr commented Mar 14, 2015

I can confirm that this is now working for me too. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ir JRuby 9000
Projects
None yet
Milestone
JRuby 9.0.0.0.pre2
Development

No branches or pull requests
3 participants
@headius @enebo @philr