JOGL commit 166e5da causes deadlock errors in Java 3D

Hi.

JOGL commit 166e5da5298b16b0acbf900004964d370cd0aa29 causes deadlock errors in Java 3D.

This commit causes the IDV (http://www.unidata.ucar.edu/software/idv/) to occasionally (but reproducibly) freeze up. This problem occurs on Windows, OS X and Linux.

Here are the relevant thread dumps :

"J3D-Renderer-1" prio=5 tid=0x00007f96dceaf800 nid=0xe103 waiting for monitor entry [0x000000011d9d5000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.awt.Component.removeHierarchyListener(Component.java:5383)
	- waiting to lock <0x00000007f8127338> (a java.awt.Component$AWTTreeLock)
	at com.jogamp.nativewindow.awt.JAWTWindow$JAWTComponentListener.detach(JAWTWindow.java:175)
	at com.jogamp.nativewindow.awt.JAWTWindow$JAWTComponentListener.access$600(JAWTWindow.java:123)
	at com.jogamp.nativewindow.awt.JAWTWindow.destroy(JAWTWindow.java:606)
	at javax.media.j3d.JoglDrawable.destroyNativeWindow(JoglDrawable.java:60)
	at javax.media.j3d.JoglPipeline.destroyContext(JoglPipeline.java:6799)
	at javax.media.j3d.Canvas3D.destroyContext(Canvas3D.java:4651)
	at javax.media.j3d.Renderer.removeCtx(Renderer.java:1551)
	- locked <0x00000007f841de58> (a java.lang.Object)
	at javax.media.j3d.Renderer.doWork(Renderer.java:372)
	at javax.media.j3d.J3dThread.run(J3dThread.java:271)


"J3D-TimerThread" prio=5 tid=0x00007f96dbc8d800 nid=0xd12f waiting for monitor entry [0x0000000117bf8000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at javax.media.j3d.MasterControl.processMessage(MasterControl.java:1102)
	- waiting to lock <0x00000007f841cf00> (a java.lang.Object)
	at javax.media.j3d.WakeupCondition.setConditionMet(WakeupCondition.java:115)
	at javax.media.j3d.WakeupCriterion.setTriggered(WakeupCriterion.java:66)
	at javax.media.j3d.TimerThread.run(TimerThread.java:128)

 
I found a forum posting related to this issue:

https://www.java.net/node/667423

Commits prior to 166e5da do not have deadlock problems. I guess changes to JAWTWindow.java may be the source of the problem.

Would it be possible to have this issue examined? I can provide more information if necessary including how to reproduce this problem in the IDV. I cannot necessarily provide a small test case, as this deadlock bug probably depends on complex interactions between our application, Java 3D, and JOGL.

Many thanks!

-Julien

Hi

The only impacting change is the call to setVisible:
https://github.com/sgothel/jogl/commit/166e5da5298b16b0acbf900004964d370cd0aa29#diff-66f89cc1abd0e7513220360faa41dab4R176

Why not rebuilding JOGL without this call and testing in your application? We can do nothing without a test case.

Can you produce the full thread dump, I want to know who has 0x00000007f841cf00 locked in your below example.

Harvey

Julien & Harvey,

Thanks for the quick response. The call to

component.setVisible(localVisibility);

is not the problem. The problem is isolated to this change (in two places)

-            component.addComponentListener(jawtComponentListener);
-            component.addHierarchyListener(jawtComponentListener);
+            component.addComponentListener(this);
+            component.addHierarchyListener(this);

There is a fair bit of locking in JAWTWindow.java which I wonder if that is the source of the problem. Where ever the "this" object is escaping to may be causing deadlock. I tried playing around with removing the locks, but that experiment went nowhere.

For your request to provide a test case, how do I do that? This deadlock bug is the result of complex interactions between IDV, VisAD, Java 3D and JOGL. If you want, I can explain how to run the IDV to reproduce this problem.

Here is the full thread dump: https://gist.github.com/julienchastang/8589559

Thanks again for your help.

-Julien

On 01/23/2014 09:49 PM, Julien [via jogamp] wrote:
> Hi.
>
> JOGL commit 166e5da5298b16b0acbf900004964d370cd0aa29 causes deadlock errors in
> Java 3D.

Thank you!

This code has already been revised, and a far less intrusive solution provided - see:
  <http://jogamp.org/git/?p=jogl.git;a=commit;h=071bdd6ce9f8c41ccecdbf8bc74f276ccd7ff651>

Bug report:
   <https://jogamp.org/bugzilla/show_bug.cgi?id=937#c5>

This also solves the dealock, since we no more change the visibility state
via JAWTWindow.

However .. looks like you are doing something not from the AWT-EDT.

~Sven

Sven,

Thanks for looking into this.

I cloned and built the latest jogl/gluegen/joal from github and I still see the deadlock problem. Note this happening on all platforms, not just OS X. You are correct, we are probably not making adequate use of the AWT-EDT.

Thanks again.

-Julien

On 01/24/2014 06:11 PM, Julien [via jogamp] wrote:
> Sven,
>
> Thanks for looking into this.
>
> I cloned and built the latest jogl/gluegen/joal from github and I still see
> the deadlock problem. Note this happening on all platforms, not just OS X. You
> are correct, we are probably not making adequate use of the AWT-EDT.
>

"we" -> maybe Java3D ..

The AWTTreeLock is acquired by Component.removeHierarchyListener
and as for _every_ AWT component, modifications shall happen on the AWT-EDT.

IMHO the Canvas3D shall offload AWT modifications to the AWT-EDT
similar to what JOGL's GLCanvas and NEWTCanvasAWT does.

However, since JAWTWindow also represents a NativeWindow instance
it would not be too bad to offload AWTTreeLock methods ourselves, i.e.:

  boolean wait = false;
  AWTEDTExecutor.singleton.invoke(wait, new Runnable() {
      @Override
      public void run() {
          ... detach ..
      } } );

Accepted as filed under Bug 952:
   <https://jogamp.org/bugzilla/show_bug.cgi?id=952>

Thank you and Emmanual (who referenced this issue).

~Sven

+++

"J3D-Renderer-1" prio=5 tid=0x00007f96dceaf800 nid=0xe103 waiting for monitor entry [0x000000011d9d5000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at java.awt.Component.removeHierarchyListener(Component.java:5383)
        - waiting to lock <0x00000007f8127338> (a java.awt.Component$AWTTreeLock)
        at com.jogamp.nativewindow.awt.JAWTWindow$JAWTComponentListener.detach(JAWTWindow.java:175)
        at com.jogamp.nativewindow.awt.JAWTWindow$JAWTComponentListener.access$600(JAWTWindow.java:123)
        at com.jogamp.nativewindow.awt.JAWTWindow.destroy(JAWTWindow.java:606)
        at javax.media.j3d.JoglDrawable.destroyNativeWindow(JoglDrawable.java:60)
        at javax.media.j3d.JoglPipeline.destroyContext(JoglPipeline.java:6799)
        at javax.media.j3d.Canvas3D.destroyContext(Canvas3D.java:4651)
        at javax.media.j3d.Renderer.removeCtx(Renderer.java:1551)
        - locked <0x00000007f841de58> (a java.lang.Object)
        at javax.media.j3d.Renderer.doWork(Renderer.java:372)
        at javax.media.j3d.J3dThread.run(J3dThread.java:271)


+++


> Thanks again.
>
> -Julien
>

On 01/27/2014 02:02 PM, Sven Gothel wrote:
>
> Accepted as filed under Bug 952:
>    <https://jogamp.org/bugzilla/show_bug.cgi?id=952>

Please try
<http://jogamp.org/deployment/archive/master/gluegen_770-joal_519-jogl_1214-jocl_920/>

~Sven

Looking through the history of this callback from the Java3d side...it really doesn't expect any AWT modification to happen in the nativewindow destruction path, which is likely why it gets surprised by JAWTWindow here...I think your solution of pushing the listener removal to the AWT-EDT on the jogl side is likely best....but if I've analyzed it wrong, I will look again and put a similar solution in place on the Java3d side.

Harvey

Sven,

Excellent! These latest changes seem to solve the deadlock problems.

Thanks immensely for your help. If you are ever through Boulder, we will have to buy a beer :-)

-Julien