Occasional java.lang.ArrayIndexOutOfBoundsException calling ScriptingContainer#runScriptlet

This sort of thing only seems likely to happen if multiple threads are stepping on each other in ThreadContext, which should not normally be possible. The case where it is possible is if the same ThreadContext is being used unconditionally for what could be multi-threaded logic, rather than always getting the current thread's ThreadContext.

We only use the public API of ScriptingContainer without any explicit use of ThreadContext that I know of.

Is it most likely that we are doing something wrong, or most likely a bug inside JRuby?

We do have multiple threads running. We use the SINGLETON LocalContextScope.

I'm sure this is happening from a logic of sharing local variables.

Uwe, "multiple threads" are created in a Ruby way? or created by Android API?

The threads are mostly created by the Android framework, but also by our Java and Ruby code.

We do use some global variables for passing call receiver and arguments, but not top level local variables.

I hope we can solve this because it makes tests and development unreliable.

I've added two debug lines to see if I can see how it goes wrong.

I have investigated a bit. The error may be that the SoftReference to ThreadContext is collected while inside a ScriptingContainer method call. When the ThreadContext is recreated on demand, it has only the top static scope, and if that is popped, any call to getCurrentScope() will fail.

What hard references should there be to ThreadContext during a call to ScriptingContainer?

I have been struggling with this for days now, and I really need help reproducing outside Ruboto.

Reproducing with Ruboto is pretty easy. Check out the project. Then start an emulator or connect a device. Then

./run_tests.sh

I have forced the same error in a JRuby tests, but I had to use

container.getProvider().getRuntime().getThreadService().disposeCurrentThread();

and I am not sure this is legal during the use of a ScriptingContainer. Is it?

Any help on this is greatly appreciated since this is currently the only blocker for the next Ruboto release.

I have an example that fails with the same symptom:

class JRUBY_6792 {
    public static void main(String[] args) {
        org.jruby.embed.ScriptingContainer container = new org.jruby.embed.ScriptingContainer();

        // Simulate a garbage collection of softreference to current context
        container.getProvider().getRuntime().getThreadService().setCurrentContext(null);

        container.put("MyConstant", 42);
        container.runScriptlet("a = 1");
        container.runScriptlet("b = 2");
    }
}

This will fail of there is a contained memory condition during a call to runScriptlet so that SoftReferences are collected.

I simulate this by triggering an OutOfMemoryError inside EmbedEvalUnitImpl#run like this:

                try {
                    java.util.List<byte[]> l = new java.util.ArrayList<byte[]>();
                    while(true) {
                        l.add(new byte[1024 * 1024]);
                    }
                } catch (OutOfMemoryError oome) {
                    System.out.println("Forced SoftReference collection: " + oome);
                }

I have checked all this in on the JRUBY-6792 branch. I tried rebasing the branch and got into some GIT trouble, so tell me if there is a problem.

Any help with this is still greatly appreciated.

OK, the reproduction I did was fixed by keeping a reference to the current ThreadContext during execution of EmbedEvalUnitImpl#run.

I have committed this to master, and it looks like the change fixes this issue. Since the error is dependent on timing, I'll run the tests a few times before closing this issue.

Multiple test runs have completed successfully, so I'm calling it fixed.

Woohoo!