JOGL commit 166e5da causes deadlock errors in Java 3D

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

JOGL commit 166e5da causes deadlock errors in Java 3D

Julien
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
Reply | Threaded
Open this post in threaded view
|

Re: JOGL commit 166e5da causes deadlock errors in Java 3D

gouessej
Administrator
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: JOGL commit 166e5da causes deadlock errors in Java 3D

hharrison
In reply to this post by Julien
Can you produce the full thread dump, I want to know who has 0x00000007f841cf00 locked in your below example.

Harvey
Reply | Threaded
Open this post in threaded view
|

Re: JOGL commit 166e5da causes deadlock errors in Java 3D

Julien
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

Reply | Threaded
Open this post in threaded view
|

Re: JOGL commit 166e5da causes deadlock errors in Java 3D

Sven Gothel
Administrator
In reply to this post by 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


signature.asc (894 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JOGL commit 166e5da causes deadlock errors in Java 3D

Julien
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
Reply | Threaded
Open this post in threaded view
|

Re: JOGL commit 166e5da causes deadlock errors in Java 3D

Sven Gothel
Administrator
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
>


signature.asc (894 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JOGL commit 166e5da causes deadlock errors in Java 3D

Sven Gothel
Administrator
In reply to this post by 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



signature.asc (894 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JOGL commit 166e5da causes deadlock errors in Java 3D

hharrison
In reply to this post by Sven Gothel
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
Reply | Threaded
Open this post in threaded view
|

Re: JOGL commit 166e5da causes deadlock errors in Java 3D

Julien
In reply to this post by Sven Gothel
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