java.lang.ArrayIndexOutOfBoundsException: 96

[Deepak Dhiman]

Upgraded vertx to 3.2.1 and quasar to 0.7.5 and getting this exception

This exception comes on first execution but not always.

java.lang.ArrayIndexOutOfBoundsException: 96

at co.paralleluniverse.fibers.Stack.popMethod(Stack.java:160)

at io.vertx.ext.sync.Sync.lambda$null$19031fba$1(Sync.java:148)

at io.vertx.ext.sync.Sync$$Lambda$79/1177668243.run(Unknown Source)

at co.paralleluniverse.strands.SuspendableUtils$VoidSuspendableCallable.run(SuspendableUtils.java:44)

at co.paralleluniverse.strands.SuspendableUtils$VoidSuspendableCallable.run(SuspendableUtils.java:32)

at co.paralleluniverse.fibers.Fiber.run(Fiber.java:1027)

at co.paralleluniverse.fibers.Fiber.run1(Fiber.java:1022)

at co.paralleluniverse.fibers.Fiber.exec(Fiber.java:732)

at co.paralleluniverse.fibers.RunnableFiberTask.doExec(RunnableFiberTask.java:95)

at co.paralleluniverse.fibers.RunnableFiberTask.run(RunnableFiberTask.java:86)

at io.vertx.ext.sync.Sync.lambda$getContextScheduler$2(Sync.java:198)

at io.vertx.ext.sync.Sync$$Lambda$33/639960983.execute(Unknown Source)

at co.paralleluniverse.fibers.FiberExecutorScheduler.execute(FiberExecutorScheduler.java:77)

at co.paralleluniverse.fibers.RunnableFiberTask.submit(RunnableFiberTask.java:289)

at co.paralleluniverse.fibers.Fiber.start(Fiber.java:1058)

at io.vertx.ext.sync.Sync.lambda$fiberHandler$0(Sync.java:148)

at io.vertx.ext.sync.Sync$$Lambda$48/1083931751.handle(Unknown Source)

at io.vertx.core.eventbus.impl.HandlerRegistration.handleMessage(HandlerRegistration.java:207)

at io.vertx.core.eventbus.impl.HandlerRegistration.handle(HandlerRegistration.java:201)

at io.vertx.core.eventbus.impl.EventBusImpl.lambda$deliverToHandler$127(EventBusImpl.java:498)

at io.vertx.core.eventbus.impl.EventBusImpl$$Lambda$77/1915922822.handle(Unknown Source)

at io.vertx.core.impl.ContextImpl.lambda$wrapTask$18(ContextImpl.java:335)

at io.vertx.core.impl.ContextImpl$$Lambda$12/1007402143.run(Unknown Source)

at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)

at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)

at java.lang.Thread.run(Thread.java:745)

Exception in Fiber "fiber-vertx.contextScheduler-10000009" java.lang.ArrayIndexOutOfBoundsException: 96

at co.paralleluniverse.fibers.Stack.popMethod(Stack.java:160)

at io.vertx.ext.sync.Sync.lambda$null$19031fba$1(Sync.java:148)

at io.vertx.ext.sync.Sync$$Lambda$79/1177668243.run(Unknown Source)

at co.paralleluniverse.strands.SuspendableUtils$VoidSuspendableCallable.run(SuspendableUtils.java:44)

at co.paralleluniverse.strands.SuspendableUtils$VoidSuspendableCallable.run(SuspendableUtils.java:32)

at co.paralleluniverse.fibers.Fiber.run(Fiber.java:1027)

[Fabio Tudone]

Hi, can you confirm that running with `-Dco.paralleluniverse.fibers.verifyInstrumentation=true` doesn't highlight any instrumentation issues? Also, which Vert.X and Quasar versions were you using before upgrading and were they working OK?

If indeed verification doesn't complain, could you try to reproduce the issue while  using a regular fork-join fiber scheduler instead of the (default) `vertx-sync` "direct" one? I setup a project that does it for a simple example application (my version of it uses Quasar 0.7.5 too): https://github.com/circlespainter/vertx-examples/tree/master/sync-examples. You can run it either from an IDE or from the command line with Maven (I updated notes about both ways in `README.adoc`), then open a browser and point it at `http://localhost:8080`. You’ll see on `stdout` a line stating (just ignore the`UnableToInstrument` exceptions, they’re harmless and will go away in a future `vertx-sync` version, see here for more details):

    [HTTPReqHandler] Running in a fiber, scheduler class: co.paralleluniverse.fibers.FiberForkJoinScheduler`

The stacktrace will show a regular fiber stacktrace of a task run by the fork-join scheduler.

(As a countercheck, you can comment out the `vertx.getOrCreateContext().put(FIBER_SCHEDULER_CONTEXT_KEY, …​)` line in `fiberhandler/Server.java` in order to use the default `vertx-sync` "direct" scheduler, in that case you’ll see on `stdout` a line stating: `[HTTPReqHandler] Running in a fiber, scheduler class: co.paralleluniverse.fibers.FiberExecutorScheduler`. The stacktrace will show a fiber started by `vertx-sync` and immediately being executed in the very same thread).

Let's see if using regular fork-join fiber scheduler makes the issue go away in your case: if it does then the issue must somehow related to the `vertx-sync` "direct" scheduler. I'm already in touch with the `vertx-sync` guys (here and here) to understand better this topic.

Thanks for posting this report, this issue could be shared by other people and it'll be useful to gather information for (and from) them too.

-- Fabio

[Deepak Dhiman]

I tried using FiberForkJoinScheduler as posted in the example but still get the same exception.

There are no instrumentation warnings. We were using vertx 3.1.0 and quasar 0.7.3, but we have made change in code, so should not say that everything works same in older version.

Also getting this exception every now and then.

WARNING: fiber Fiber@10000137:fiber-10000137[task: ParkableForkJoinTask@22b98c06(Fiber@10000137), target: co.paralleluniverse.strands.SuspendableUtils$VoidSuspendableCallable@489cb53c, scheduler: co.paralleluniverse.fibers.FiberForkJoinScheduler@7b739906] is blocking a thread (Thread[ForkJoinPool-default-fiber-pool-worker-1,5,main]).

at sun.misc.Unsafe.park(Native Method)

at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)

at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)

at org.apache.commons.pool2.impl.LinkedBlockingDeque.pollFirst(LinkedBlockingDeque.java:569)

at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:441)

at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:361)

at redis.clients.util.Pool.getResource(Pool.java:49)

at redis.clients.jedis.JedisPool.getResource(JedisPool.java:99)

at co.paralleluniverse.fibers.redis.JedisPool.getResource(JedisPool.java:103)

at co.paralleluniverse.fibers.redis.JedisPool.getResource(JedisPool.java:28)

at co.paralleluniverse.fibers.redis.Utils$FiberRedisStringPubSubListener.lambda$message$5225437b$1(Utils.java:351)

at co.paralleluniverse.fibers.redis.Utils$FiberRedisStringPubSubListener$$Lambda$125/1711549328.run(Unknown Source)

at co.paralleluniverse.strands.SuspendableUtils$VoidSuspendableCallable.run(SuspendableUtils.java:44)

at co.paralleluniverse.strands.SuspendableUtils$VoidSuspendableCallable.run(SuspendableUtils.java:32)

at co.paralleluniverse.fibers.Fiber.run(Fiber.java:1027)

[Fabio Tudone]

Can you share the exception stacktrace when using "FiberForkJoinScheduler"?

The "fiber ... is blocking a thread ..." warning is meant to let the developer know if a fiber is using a thread for too long (for example it could be because of thread-blocking I/O or a long-running computation) because this could prevent other fibers from progressing fast enough; it can be harmless though, especially if it happens only occasionally or during the initial warmup (I believe this is the case as it happens in a resource pool). It's possible to turn it off with "-Dco.paralleluniverse.fibers.detectRunawayFibers=false".

-- Fabio