Deadlock during JOGL initialization

Hi guys,

When deploying my applet with JOGL RC9, initialization of the applet freezes sometimes. It seems to happen just when the GLCanvas is set visible for the first time. It happens only under certain circumstances (computer, browser, type of embedding, deployment), but there is no pattern. It is repeatable however.

I fired up VisualVM to have a look and it reported a deadlock:

Found one Java-level deadlock:
=============================
"SysExecutionThead":
  waiting for ownable synchronizer 0x1f315930, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
  which is held by "TimerQueue"
"TimerQueue":
  waiting for ownable synchronizer 0x1f31f0e0, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
  which is held by "AWT-EventQueue-2"
"AWT-EventQueue-2":
  waiting to lock monitor 0x04adf364 (object 0x1f605ed0, a sun.awt.PostEventQueue),
  which is held by "TimerQueue"

Java stack information for the threads listed above:
===================================================
"SysExecutionThead":
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x1f315930> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
        at java.util.concurrent.locks.LockSupport.park(Unknown Source)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Unknown Source)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source)
        at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(Unknown Source)
        at java.util.concurrent.locks.ReentrantLock.lock(Unknown Source)
        at sun.awt.SunToolkit.flushPendingEvents(Unknown Source)
        at java.awt.EventQueue.postEvent(Unknown Source)
        at java.awt.EventQueue.invokeLater(Unknown Source)
        at javax.swing.SwingUtilities.invokeLater(Unknown Source)
        at com.sun.deploy.uitoolkit.impl.awt.ui.SwingConsoleWindow$26.execute(Unknown Source)
        at sun.plugin.util.PluginSysUtil$SysExecutionThread.run(Unknown Source)
"TimerQueue":
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x1f31f0e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
        at java.util.concurrent.locks.LockSupport.park(Unknown Source)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Unknown Source)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source)
        at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(Unknown Source)
        at java.util.concurrent.locks.ReentrantLock.lock(Unknown Source)
        at java.awt.EventQueue.postEventPrivate(Unknown Source)
        at java.awt.EventQueue.postEvent(Unknown Source)
        at sun.awt.PostEventQueue.flush(Unknown Source)
        - locked <0x1f605ed0> (a sun.awt.PostEventQueue)
        at sun.awt.SunToolkit.flushPendingEvents(Unknown Source)
        at java.awt.EventQueue.postEvent(Unknown Source)
        at java.awt.EventQueue.invokeLater(Unknown Source)
        at javax.swing.SwingUtilities.invokeLater(Unknown Source)
        at javax.swing.Timer$1.run(Unknown Source)
        at javax.swing.Timer$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.swing.Timer.post(Unknown Source)
        at javax.swing.TimerQueue.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
"AWT-EventQueue-2":
        at sun.awt.PostEventQueue.noEvents(Unknown Source)
        - waiting to lock <0x1f605ed0> (a sun.awt.PostEventQueue)
        at sun.awt.SunToolkit.isPostEventQueueEmpty(Unknown Source)
        at java.awt.EventQueue.detachDispatchThread(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)



I can't make anything of the stack traces above, as I don't see any JOGL methods.

Do the JOGL developers know what is going on? Is there any way in which I can further research this or add to the solution? Note that I tried to use -Djnlp.nativewindow.debug=all -Djnlp.jogl.debug=all but can't get it to work with an applet in a browser.

Thanks!

On 07/23/2012 03:43 PM, toffegast [via jogamp] wrote:
> Hi guys,
>
> When deploying my applet with JOGL RC9, initialization of the applet freezes
> sometimes. It seems to happen just when the GLCanvas is set visible for the
> first time. It happens only under certain circumstances (computer, browser,
> type of embedding, deployment), but there is no pattern. It is repeatable
> however.

Please check w/ latest source code / autobuilds,
locking code has been revised.

However .. the lock mentioned below doesn't seem to be JOGL
related.

>
> I can't make anything of the stack traces above, as I don't see any JOGL
methods.
>
> Do the JOGL developers know what is going on? Is there any way in which I can
> further research this or add to the solution? Note that I tried to use
> -Djnlp.nativewindow.debug=all -Djnlp.jogl.debug=all but can't get it to work
> with an applet in a browser.
>

With latest source code, it will work .. sorry.
Next release soon.

> Thanks!

Hi

Do you reproduce this bug when using your program as an application rather than as an applet?

Thanks for the info so far. I will see what the autobuilds do.

I've ran the code as an application, and didn't run into the problem. But then, in many situations the applet runs fine too. So I wouldn't draw too many conclusions from that yet.

I ran my applet with the latest autobuild - b784. The problem remains. The deadlock that VisualVM reports looks exactly the same.

I was able to enable debugging output this time. The last thing that was logged before the freeze was:



As the deadlock seems to concern JVM code only (no JOGL or my own code), am I right in assuming that we are looking at a JVM bug here?

Thanks again.

Reentrant locks are used in JOGL, it might come from that but I'm not sure.

On 07/24/2012 11:48 AM, toffegast [via jogamp] wrote:
> I ran my applet with the latest autobuild - b784. The problem remains. The
> deadlock that VisualVM reports looks exactly the same.
>
> I was able to enable debugging output this time. The last thing that was
> logged before the freeze was:

Sorry, I can only see a 'cut off' picture w/ the GLCapabilities ..

Can you please do:
  > jstack -l PID-OF-JAVA >> stack.txt 2>&1

then attach the file stack.txt .. thx

~Sven