Posted by
Sven Gothel on
Aug 14, 2012; 1:55am
URL: https://forum.jogamp.org/AWT-JOGL-Deadlock-Revisited-tp4025772p4025800.html
On 08/13/2012 10:28 PM, rhatcher [via jogamp] wrote:
> Hi Julien,
>
> I wish I could whittle it down to something small, and if I manage to do that
> I will be happy to provide a test case. Unfortunately the situation is
> complex and I suspect the complexity is a big part of the problem.
>
> Since my original post the problem has changed a little bit. I built GlueGen
> and JOGL from repositories I cloned last Friday 08/10/2012 (I guess this would
> be something slightly after RC10 by JogAmp's reckoning) to see if the deadlock
> issue went away. So far I haven't seen any more deadlocks, or at least
> nothing that's being reported as a deadlock.
Yes, RC10 (latest sources) includes the deadlock fix.
>
> However...
>
> I am still frequently seeing situations where no drawing takes place and the
> AWT event queue seems to be locked up across the board (for example menus
> don't work either) even though no deadlock is reported by jstack.
>
> Every time this happens I can get in the debugger and find a timer thread that
> appears to be stuck waiting on a java.awt.EventQueue$1InvocationLock with this
> backtrace:
>
> "Timer-6" prio=10 tid=0xa5319c00 nid=0x5fce in Object.wait() [0xa5d69000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xad29c688> (a java.awt.EventQueue$1AWTInvocationLock)
Your jstack shows:
"AWT-EventQueue-0" prio=10 tid=0xa668e800 nid=0x5f7e runnable [0xa635c000]
java.lang.Thread.State: RUNNABLE
at java.lang.StringBuilder.append(StringBuilder.java:132)
at java.lang.Object.toString(Object.java:237)
at java.lang.String.valueOf(String.java:2902)
.. so for some reason it produces a String for-ever it seems like ?
> at java.lang.Object.wait(Object.java:503)
> at java.awt.EventQueue.invokeAndWait(EventQueue.java:1232)
> - locked <0xad29c688> (a java.awt.EventQueue$1AWTInvocationLock)
> at jogamp.common.awt.AWTEDTExecutor.invoke(AWTEDTExecutor.java:53)
> at
> jogamp.opengl.awt.AWTThreadingPlugin.invokeOnOpenGLThread(AWTThreadingPlugin.java:103)
>
> at jogamp.opengl.ThreadingImpl.invokeOnOpenGLThread(ThreadingImpl.java:206)
> at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:172)
> at javax.media.opengl.Threading.invoke(Threading.java:191)
> at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:428)
> at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:74)
> at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:142)
> at
> com.zedasoft.cba.view.DisplaySetAnimator.display(DisplaySetAnimator.java:105)
Minor note: Looks like you override AnimatorBase.display() w/ your
DisplaySetAnimator.display().
> at com.jogamp.opengl.util.FPSAnimator$1.run(FPSAnimator.java:128)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
>
> Here's the full jstack output from one failed run: jstack2.out
> <
http://forum.jogamp.org/file/n4025798/jstack2.out>
>
> My observation is that once it's in this condition it never recovers. Just
> for good measure I set a breakpoint higher up in the backtrace to verify that
> it's never returning from the display call.
>
> I've been poking around in the lower levels of all this stuff for most of the
> day trying to make sense of where it's getting hung up. The problem happens
> relatively frequently, so if you have any suggestions about ways I might trap
> the root cause I will be glad to try them. Maybe that will help me learn
> enough to produce a smaller example.
See above .. AWT EDT seems to be busy w/ producing a string ?
We would need a small unit test to reproduce the issue of yours
and to see whether it's JOGL who causes this 'overload'.
IMHO .. it's not.
~Sven