Advice debugging deadlock

I recently started a new job where I am employed to maintain an existing tool for visualising gene expression using a 3D graph. One of my first tasks was to move from using a customised version of the JOGL 1.1.1a binding to the official JOGL 2, so that we could build the project without relying on older unsupported code. For the most part this went relatively smoothly and I successfully managed to get the tool working on Windows.

I then moved to my Linux installation to verify that all was well in that domain. Unfortunately I get a deadlock on start up and fundamentally don't have the first clue how to go about resolving it. It /appears/ to be JOGL related, but my experience with JOGL and indeed Java is limited, so I may be mistaken (I'm really more of a C/C++ guy).

I'm using the rc11 build but I have also tried a recent automated build from the website which made no obvious difference.

Here is the output of a run with -Djogamp.debug=true: http://codepad.org/xDNZFbDW
Here is a dump of the thread state: http://codepad.org/yCFfrCGd

I believe this part is pertinent:
"main-SharedResourceRunner" daemon prio=10 tid=0x00007f1700ac5800 nid=0x61e1 in Object.wait() [0x00007f16e04fd000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000007cecdd060> (a jogamp.opengl.SharedResourceRunner)
        at java.lang.Object.wait(Object.java:503)
        at jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:240)
        - locked <0x00000007cecdd060> (a jogamp.opengl.SharedResourceRunner)
        at java.lang.Thread.run(Thread.java:722)

The code, should you be adventurous enough: https://www.dropbox.com/s/g13ur7g8samc3ct/biolayout.tar.gz

Any guidance/advice/help that you guys could offer is greatly appreciated. Don't hesitate to ask for me to generate further debug output should it be helpful.

TIA.

Oops, just noticed codepad trimmed my log. Here it is directly: http://timang.us/bl-deadlock-stdout.txt

Hi

Please provide a short test case to help us to reproduce your bug.

It took a while but here we go: https://www.dropbox.com/s/pby1hdy9foun6dy/jogamp-test.tar.gz

I realise this code may seem a bit unorthodox, but it works OK on Windows. On Linux the app never becomes responsive and the UI isn't drawn at all. I'm not seeing anything obviously wrong in the code above, but any suggestions are welcome.

Thanks.

Why do you create an OpenGL context? I don't see what you're trying to achieve.

To be honest I'm not 100% certain myself. I've inherited this code so I'm at the mercy of what's there to some extent. The OpenGL contexts are used in several places including as a means of detecting hardware features and to enable GPGPU techniques to accelerate some algorithms used (in the sense of using texture upload and shaders to simulate general purpose computing).

I understand that this probably appears an odd thing to do, but the fact remains that it seems fine on Windows, but fails on Linux. Any clues?

Try not to use a JDialog and get the context once it is created instead of creating it by yourself. You can get the context in the GLEventListener, in init() or in display(), typically when you know it is current.

That all sounds eminently sensible. The only problem I can see is being able to control when init or display is called. Is there a particular  method or action that can be performed on a GLCanvas that will ensure init is called for example?

I imagine the current method of manually creating things is used to avoid this issue. Perhaps there are some examples of people using JOGL2 to do GPGPU style computation somewhere?

Why do you need to control when init() or display() is called? When you need a current OpenGL context to perform an operation, you should get it in your own implementation of GLEventListener that you set to your canvas and you should perform them in init() or display(). You can even create a queue, put some tasks into it from another thread with proper synchronization and execute these tasks in display(). Another solution consists in getting the context in init() and explicitly making it current (and releasing it) but it is more dangerous as some drivers are not very tolerant, they don't handle an OpenGL context made current on another thread than the one used to create it (especially under Windows). Maybe look at the renderer based on JOGL 2.0 used in Ardor3D, it's a nice source of inspiration to understand how to do that even though it is a bit complicated.

Well, I've got it mostly working now. The only problem I'm having is that doing anything lengthy in init or display of course locks up the EDT, making the app unresponsive until the work is done. I guess in this case I have to use your latter suggestion whereby I save the context in init and do the actual work in a separate thread which tries to make it current?

timangus wrote

Well, I've got it mostly working now.

How did you solve your problem?

timangus wrote

The only problem I'm having is that doing anything lengthy in init or display of course locks up the EDT, making the app unresponsive until the work is done. I guess in this case I have to use your latter suggestion whereby I save the context in init and do the actual work in a separate thread which tries to make it current?

At first, separate the operations that require a current OpenGL context from the others. Then, you can execute the operations that don't require such a context on another thread. You can use a separate thread for those requiring a current OpenGL context too, but it won't work with some drivers. What kind of lengthy operation do you do?