JOGL2 conflicting with GTK?

Hello everyone,

I managed to reproduce a very strange bug with JOGL2 on my debian box with Gnome: when I attempt to display a JFrame containing a JSplitpane with a JTree and a GLCanvas as children, the application happens to behave randomly in one of the two ways described below:
- a seg fault occurs in pthread_mutex_lock (libpthread.so) before the JFrame is visible on screen. Here is the error report hs_err_pid9548.log 
- the event dispatching thread locks in some methods of GTKNativeEngine. Depending on the machine, it hangs either in GTKNativeEngine.native_paint_flat_box or in GTKNativeEngine.native_paint_expander. As far as I know, the latter is the method in charge of drawing a little triangle on the left of a node in the JTree in order to expand or collapse it. The bug disappears if the TreeUI is not SynthTreeUI (the default), certainly because other tree UIs do not seem to draw any widget as tree node expander and therefore do not call native_paint_expander.

Of course, if I remove the GLCanvas or the JTree from my app, everything works fine. I tried to replace the GLCanvas by a simple Canvas or by a JPanel and I could not reproduce the bug.

It looks like the bug is not reproducible if the window manager is Compiz. I reproduced it with metacity.

I really cannot figure out the link between GTK and JOGL2. Does anybody have an idea?

To reproduce it on linux, you can run this very simple application.

Many thanks to anybody that is willing to help me!
Cyrille

please insert GLProfile.initSingleton() as first statement in main() and see if it helps.

regards,
michael

On 08/01/2010 10:41 PM, Cyrille [via jogamp] wrote:

Hello everyone,

I managed to reproduce a very strange bug with JOGL2 on my debian box with Gnome: when I attempt to display a JFrame containing a JSplitpane with a JTree and a GLCanvas as children, the application happens to behave randomly in one of the two ways described below:
- a seg fault occurs in pthread_mutex_lock (libpthread.so) before the JFrame is visible on screen. Here is the error report hs_err_pid9548.log 
- the event dispatching thread locks in some methods of GTKNativeEngine. Depending on the machine, it hangs either in GTKNativeEngine.native_paint_flat_box or in GTKNativeEngine.native_paint_expander. As far as I know, the latter is the method in charge of drawing a little triangle on the left of a node in the JTree in order to expand or collapse it. The bug disappears if the TreeUI is not SynthTreeUI (the default), certainly because other tree UIs do not seem to draw any widget as tree node expander and therefore do not call native_paint_expander.

Of course, if I remove the GLCanvas or the JTree from my app, everything works fine. I tried to replace the GLCanvas by a simple Canvas or by a JPanel and I could not reproduce the bug.

It looks like the bug is not reproducible if the window manager is Compiz. I reproduced it with metacity.

I really cannot figure out the link between GTK and JOGL2. Does anybody have an idea?

To reproduce it on linux, you can run this very simple application.

Many thanks to anybody that is willing to help me!
Cyrille

---

View message @ http://jogamp.762907.n3.nabble.com/JOGL2-conflicting-with-GTK-tp1013991p1013991.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

Thanks Michael. This is a good idea, I'll try that this evening and give you some feedback.

Cyrille

I inserted GLProfile.initSingleton() at the very beginning of the main() method and it fixed the issue!

Thanks again, Michael, I certainly wouldn't have thought of it without your help.
BTW, would there be a way to make this method mandatory? I mean, it would be helpful to detect that the client code forgot to initialize the GLProfile class, since troubleshooting this kind of bug is very difficult.

Thanks,
Cyrille

We are about to evaluate this issue .. still.

initSingleton() is called within our code at 1st anyways (static initializer of GLProfile),
but there is currently no way to verify if another native or java call to the underlying
native windowing system has been made (which multithreading initialization is the issue here).

If anybody knows how to query if an X11 call has been already issued within a thread
[on a given display?] that would be great, since then we cannot initialize multithreading anymore
using XInitThreads() - too later. The latter was your issue here ..
If this is not possible (the current state) we will either opt-out or opt-in this behavior,
meaning that without XInitThreads we may have to block the whole X11[/AWT] usage for
every call - the prev. behavior.

The lack of using XInitThreads() is clearly a issue with the 'parent' application (here AWT),
and a work around is costly .. let's see.

~Sven