Bug 494 - Applications hang when making base frame visible
Summary: Applications hang when making base frame visible
Status: RESOLVED WORKSFORME
Alias: None
Product: Jogl
Classification: JogAmp
Component: x11 (show other bugs)
Version: 2
Hardware: pc_all linux
: --- major
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2011-04-10 23:23 CEST by Bill Clark
Modified: 2011-04-16 01:48 CEST (History)
1 user (show)

See Also:
Type: ---
SCM Refs:
Workaround: ---


Attachments
output of test.sh (37.75 KB, text/x-log)
2011-04-10 23:23 CEST, Bill Clark
Details
test case (2.54 KB, text/x-java)
2011-04-11 02:09 CEST, Bill Clark
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Clark 2011-04-10 23:23:55 CEST
Created attachment 248 [details]
output of test.sh

Running Ubuntu 10.04 on both 32 bit and 64 bit pcs - test.log from the 32 bit OS.
JOGL build: Release candidate 2 (jogl-2.0-b23-20110303-linux-i586) - problem started with devbuild b308 and continues to present. Build b303 still works well.
OpenGL: NVidia driver 260.19.26 - covers up to OpenGL 3.3.
Graphics card: Nvidia GeForce GTS 250.
Java version: jdk1.6.0_23.

Error message (from command line only - just hangs in Eclipse):
Nativewindow X11 IOError: Display 0x81696d0 (:0.0): Resource temporarily unavailable
Comment 1 Bill Clark 2011-04-11 02:09:13 CEST
Created attachment 249 [details]
test case
Comment 2 Wade Walker 2011-04-12 02:40:06 CEST
Running on CentOS 5.5 from within Eclipse, the app freezes after it prints this (and I can't close the window):

Info: XInitThreads() called for concurrent Thread support
GL3 is availableProfile: GLProfile[GL2/GL2]
Xlib: unexpected async reply (sequence 0xa4)!
Xlib: sequence lost (0x10000 > 0xa4) in reply type 0x21!

But when I change GLProfile.initSingleton( true ) to GLProfile.initSingleton( false ), the app works correctly and I get this output:

Info: XInitThreads() called for concurrent Thread support
GL3 is availableProfile: GLProfile[GL2/GL2]
Card Vendor: NVIDIA Corporation
GL Version: 3.0.0 NVIDIA 260.19.29
Renderer: Quadro NVS 295/PCI/SSE2

Could you try changing/removing GLProfile.initSingleton() to see if it makes a difference on your machine?

My understanding was that GLProfile.initSingleton() is supposed to be optional, so your program should work without it. Not sure what's supposed to happen if you tell it "true" when you're not actually before all other X calls -- Sven?
Comment 3 Bill Clark 2011-04-12 18:03:56 CEST
(In reply to comment #2)
>
> But when I change GLProfile.initSingleton( true ) to GLProfile.initSingleton(
> false ), the app works correctly and I get this output:
> 
Calling initSingleton(false) fixed all my hangs as well. the call with true wasn't the very first piece of code executed just close to it. When I make the call to initSingleton(true) as the very first thing in main() it also works perfectly. Thanks for your work!
Comment 4 Wade Walker 2011-04-13 02:37:21 CEST
Let's wait and see what Sven says -- I didn't think it should be possible to crash an app by using initSingleton() wrong :)
Comment 5 Sven Gothel 2011-04-16 01:48:32 CEST
Re comment 2
> My understanding was that GLProfile.initSingleton() is supposed to be optional,
> so your program should work without it. Not sure what's supposed to happen if
> you tell it "true" when you're not actually before all other X calls -- Sven?

initSingleton(boolean firstUIActionOnProcess)

  http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GLProfile.html#initSingleton%28boolean%29

The parameter 'firstUIActionOnProcess' shall reflect the situation
whether any other UI toolkit (UI-TK) operation has been issued before using JOGL (calling initSingleton(boolean)) in the process.

In case initSingleton(boolean) is not called explicitly, 
JOGL will implicitly call 'initSingleton(false)'.

If 'firstUIActionOnProcess' is 'true'
JOGL will assume safe multithreading usage of the UI-TK,
otherwise expensive locking of the UI-TK must be utilized (sequential use).

This is currently true for X11 only and related to the XInitThreads() call,
  http://tronche.com/gui/x/xlib/display/XInitThreads.html

Exception: If something else uses the UI-TK (X11) before JOGL in the process,
but is thread safe due to calling XInitThreads() upfront, 
you _can_ pass 'true' as a parameter.

In case of IDEs, applets, etc .. where JOGL is not the 1st UI-TK user in the process
and the aforementioned did not make UI-TK thread safe (XInitThreads()),
you shall pass 'false' as it's argument.

Re comment 3
> Calling initSingleton(false) fixed all my hangs as well. the call with true
> wasn't the very first piece of code executed just close to it. When I make the
> call to initSingleton(true) as the very first thing in main() it also works
> perfectly. Thanks for your work!

This behavior reflects the API doc and the above description.

Re comment 4
> Let's wait and see what Sven says -- I didn't think it should be possible to
> crash an app by using initSingleton() wrong :)

If you explicitly issue 'initSingleton(true)' in a situation where eg the IDE
used the UI-TK before JOGL in a non thread safe manner (no call to XInitThreads()),
then indeed you could crash the process.

However, not calling 'initSingleton(boolean)' at all should be safe,
since JOGL will implicitly call 'initSingleton(false)'.