| Summary: | Application freeze with GLCanvas / GLJPanel and Mesa 8 (Software/Hardware) | ||
|---|---|---|---|
| Product: | [JogAmp] Jogl | Reporter: | Cornelius <cornelius-brand> |
| Component: | awt | Assignee: | Sven Gothel <sgothel> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | misio.it, sylvestre, xerxes |
| Priority: | P1 | ||
| Version: | 2 | ||
| Hardware: | pc_x86_64 | ||
| OS: | linux | ||
| See Also: | https://launchpad.net/bugs/965798 | ||
| Type: | --- | SCM Refs: |
gluegen 1c03dfd6d1939a46018583419956e350e531f4fe
gluegen e2abb9583faf4b3dac6094fcd311475777528b8e
gluegen e9e61421ef6009e6788998c471d1d3d30aaefea6
jogl 56434e48876a85e027bca5463afdc86929d025cf
jogl 7ef27943edd08dc02752b1eef6760c35877fc098
|
| Workaround: | --- | ||
| Attachments: | Output of the OpenGL gears unit test | ||
Erroneous behavior reproduced w/ Mesa 8.0.1 Intel HD3000, OpenJDK .. see below.
+++
Your Platform data:
Platform: LINUX / Linux 3.0.0-16-generic (os), amd64 (arch) 4 cores
MachineDescription: runtimeValidated true, littleEndian true, 32Bit false, primitive size / alignment:
Platform: Java Version: 1.6.0_23, VM: OpenJDK 64-Bit Server VM, Runtime: OpenJDK Runtime Environment
GL_VENDOR Tungsten Graphics, Inc
GL_VERSION 2.1 Mesa 7.11
Your 'deadlock' due to driver issues:
"main-SharedResourceRunner" daemon prio=10 tid=0x00007f7374302800 nid=0xdf9 runnable [0x00007f736f112000]
java.lang.Thread.State: RUNNABLE
at jogamp.opengl.x11.glx.GLX.dispatch_glXMakeContextCurrent1(Native Method)
at jogamp.opengl.x11.glx.GLX.glXMakeContextCurrent(GLX.java:936)
"AWT-EventQueue-0" prio=10 tid=0x00007f73742b7000 nid=0xdf8 runnable [0x00007f7370339000]
java.lang.Thread.State: RUNNABLE
at jogamp.opengl.x11.glx.GLX.dispatch_glXMakeContextCurrent1(Native Method)
at jogamp.opengl.x11.glx.GLX.glXMakeContextCurrent(GLX.java:936)
+++
Mine #01:
Platform: LINUX / Linux 3.0.0-16-generic (os), amd64 (arch) 4 cores
MachineDescription: runtimeValidated true, littleEndian true, 32Bit false, primitive size / alignment:
Platform: Java Version: 1.6.0_23, VM: OpenJDK 64-Bit Server VM, Runtime: OpenJDK Runtime Environment
OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre11-0ubuntu1.11.10.2)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
GL_VENDOR ATI Technologies Inc.
GL_RENDERER ATI Radeon HD 5800 Series
GL_VERSION 3.0.11399 Compatibility Profile Context
Using the same flags "-Dsun.java2d.noddraw=true -Dsun.java2d.opengl=false"
I run the same test w/ Oracle's JRE and as expected (our jenkins builds), no failures neither.
+++
Mine #02:
Platform: LINUX / Linux 3.0.0-16-generic (os), amd64 (arch) 4 cores
MachineDescription: runtimeValidated true, littleEndian true, 32Bit false, primitive size / alignment:
Platform: Java Version: 1.6.0_23, VM: OpenJDK 64-Bit Server VM, Runtime: OpenJDK Runtime Environment
OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre11-0ubuntu1.11.10.2)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
GL_VENDOR Tungsten Graphics, Inc
GL_RENDERER Mesa DRI Intel(R) Sandybridge Desktop
GL_VERSION 3.0 Mesa 8.0.1
"AWT-EventQueue-0" prio=10 tid=0x00007f28582ae800 nid=0x1703 runnable [0x00007f2855850000]
java.lang.Thread.State: RUNNABLE
at jogamp.opengl.x11.glx.GLX.dispatch_glXMakeContextCurrent1(Native Method)
at jogamp.opengl.x11.glx.GLX.glXMakeContextCurrent(GLX.java:936)
Well, turns out: 1 - OpenJDK/Oracle JVM makes no diff 2 - Mesa 7.11 works 3 - Mesa 8.0.1 (soft/hard) / AWT freezes at glXMakeCurrent or glXMakeContextCurrent So I tried - locking: none - X11 Error Handler messages: none - ? Will dig deeper. P1 Blocker, since any configuration w/ Linux + Mesa 8.0.1 is affected, which is the soon to be default setup. Freeze happens always when glXMakeCurrent is invoked on the AWT EDT .. Works w/ Java system property "-Dsun.java2d.opengl=True" Works also if: "-Dsun.java2d.opengl=false" and no GLX command is issued from the AWT EDT. currently Investigating the root cause. Freeze: +++ LIBGL_ALWAYS_SOFTWARE=true GL_RENDERER = Gallium 0.4 on llvmpipe (LLVM 0x300) GL_VERSION = 2.1 Mesa 8.0.2 GL_VENDOR = VMware, Inc. "8.0.2+git20120322+8.0.0bf0ba44-0ubuntu0sarvatt~oneiric" +++ OK (compiled w/ gallium only, no DRI): +++ - 8.0 branch GL_RENDERER = Gallium 0.4 on llvmpipe (LLVM 0x300) GL_VERSION = 2.1 Mesa 8.0.2 (git-54f7391) GL_VENDOR = VMware, Inc. +++ Validating a complete compilation .. I excessively tried to reproduce the 'freeze' bug w/ a self compiled Mesa8*
libGL.so.1 w/o any luck.
You see below, I used the branch 8.0, as well as master.
Either the pre-compiled 'ppa' package is somewhat broken (their patches)
or I was just not able to reproduce the build configuration
which triggers the 'bug'.
>
> OK (compiled w/ gallium only, no DRI):
> +++
>
> - 8.0 branch
>
> GL_RENDERER = Gallium 0.4 on llvmpipe (LLVM 0x300)
> GL_VERSION = 2.1 Mesa 8.0.2 (git-54f7391)
> GL_VENDOR = VMware, Inc.
> +++
>
> Validating a complete compilation ..
Mesa3D, branch 8.0, tip 54f7391664d2cffe1f719d11fec1f18db672be5d
Result OK
Compiled w/ gallium, DRI, intel drivers using ./configure and
using llvm-3.0 on Ubuntu 11.10 / kernel 3.0.0-16-generic.
GL_VENDOR: Tungsten Graphics, Inc
GL_RENDERER: Mesa DRI Intel(R) Sandybridge Desktop
GL_VERSION: 2.1 Mesa 8.0.2 (git-54f7391)
GL_VENDOR: VMware, Inc.
GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 0x300)
GL_VERSION: 2.1 Mesa 8.0.2 (git-54f7391)
+++
Mesa3D, branch master, tip
Result OK
Compiled w/ gallium, DRI, intel drivers using ./configure and
using llvm-3.0 on Ubuntu 11.10 / kernel 3.0.0-16-generic.
./configure
GL_VENDOR: Tungsten Graphics, Inc
GL_RENDERER: Mesa DRI Intel(R) Sandybridge Desktop
GL_VERSION: 2.1 Mesa 8.1-devel (git-2c77837)
DRI drivers: i915 i965 nouveau r200 radeon swrast
GLX: DRI-based
llvm-version: 3.0
Gallium dirs: auxiliary drivers state_trackers
Target dirs: dri-r300 dri-r600 dri-swrast dri-vmwgfx
Winsys dirs: radeon/drm svga/drm sw sw/dri
Driver dirs: galahad identity llvmpipe noop r300 r600 rbug softpipe svga trace
Trackers dirs: dri
CFLAGS: -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O2 -fPIC
CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -fPIC
Macros: -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -D__STDC_CONSTANT_MACROS -DUSE_X86_64_ASM
+++
./configure --disable-gallium-llvm --with-gallium-drivers=swrast
GL_VENDOR: VMware, Inc.
GL_RENDERER: Gallium 0.4 on softpipe
GL_VERSION: 3.0 Mesa 8.1-devel (git-2c77837)
GL_VENDOR: Tungsten Graphics, Inc
GL_RENDERER: Mesa DRI Intel(R) Sandybridge Desktop
GL_VERSION: 2.1 Mesa 8.1-devel (git-2c77837)
DRI drivers: i915 i965 nouveau r200 radeon swrast
GLX: DRI-based
llvm: no
Gallium dirs: auxiliary drivers state_trackers
Target dirs: dri-swrast
Winsys dirs: sw sw/dri
Driver dirs: galahad identity noop rbug softpipe trace
Trackers dirs: dri
CFLAGS: -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O2 -fPIC
CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -fPIC
Macros: -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DUSE_X86_64_ASM
+++
./configure -disable-gallium-llvm --with-gallium-drivers=swrast --with-dri-drivers=i915,i965 \
--enable-shared-glapi --with-egl-platforms=x11,drm
GL_RENDERER = Mesa DRI Intel(R) Sandybridge Desktop
GL_VERSION = 2.1 Mesa 8.1-devel (git-2c77837)
GL_VENDOR = Tungsten Graphics, Inc
GL_RENDERER = Gallium 0.4 on softpipe
GL_VERSION = 3.0 Mesa 8.1-devel (git-2c77837)
GL_VENDOR = VMware, Inc.
DRI drivers: i915 i965
GLX: DRI-based
EGL platforms: x11 drm
EGL drivers: builtin:egl_glx
llvm: no
Gallium: yes
Gallium dirs: auxiliary drivers state_trackers
Target dirs: dri-swrast
Winsys dirs: sw sw/dri
Driver dirs: galahad identity noop rbug softpipe trace
Trackers dirs: dri
CFLAGS: -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O2 -fPIC
CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -fPIC
Macros: -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DUSE_X86_64_ASM
+++
./configure --disable-gallium-llvm --with-gallium-drivers=swrast --enable-glx-tls --enable-xlib-glx
GL_VENDOR: Brian Paul
GL_RENDERER: Mesa X11
GL_VERSION: 2.1 Mesa 8.1-devel (git-2c77837)
DRI drivers: i915 i965 nouveau r200 radeon swrast
GLX: Xlib-based
llvm: no
Gallium dirs: auxiliary drivers state_trackers
Target dirs: dri-swrast libgl-xlib
Winsys dirs: sw sw/dri sw/xlib
Driver dirs: galahad identity noop rbug softpipe trace
Trackers dirs: dri glx
CFLAGS: -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O2 -fPIC
CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -fPIC
Macros: -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_XSHM -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DUSE_X86_64_ASM
Using build options from the 'affected' https://code.launchpad.net/~xorg-edgers, https://launchpadlibrarian.net/96250226/buildlog_ubuntu-oneiric-amd64.mesa_8.0.1%2Bgit20120310%2B8.0.437ed1fa-0ubuntu0sarvatt~oneiric_BUILDING.txt.gz [master branch .. tip 2c778375a1356ffb8db1522bc3fc64c568c35cb1] No freeze .. ./configure --prefix=/home/jogamp/mesa-master-ubuntu --with-driver=dri --with-dri-drivers="i915 i965" --enable-glx-tls --enable-shared-dricore --enable-shared-glapi --enable-texture-float --enable-xa --enable-driglx-direct --with-egl-platforms="x11 drm" --disable-gallium-llvm --with-gallium-drivers="swrast" --disable-glu CFLAGS="-Wall -g -O2" CXXFLAGS="-Wall -g -O2" GL_VENDOR: VMware, Inc. GL_RENDERER: Gallium 0.4 on softpipe GL_VERSION: 3.0 Mesa 8.1-devel (git-2c77837) GL_VENDOR: Tungsten Graphics, Inc GL_RENDERER: Mesa DRI Intel(R) Sandybridge Desktop GL_VERSION: 3.0 Mesa 8.1-devel (git-2c77837) DRI drivers: i915 i965 DRI driver dir: ${libdir}/dri GLX: DRI-based EGL: yes EGL platforms: x11 drm EGL drivers: builtin:egl_glx llvm: no Gallium dirs: auxiliary drivers state_trackers Target dirs: dri-swrast Winsys dirs: sw sw/dri Driver dirs: galahad identity noop rbug softpipe trace Trackers dirs: dri xa CFLAGS: -Wall -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -Wall -g -O2 -fPIC CXXFLAGS: -Wall -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -Wall -g -O2 -fPIC Macros: -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DUSE_X86_64_ASM Also Ok for the 8.0 tip 54f7391664d2cffe1f719d11fec1f18db672be5d GL_VENDOR: VMware, Inc. GL_RENDERER: Gallium 0.4 on softpipe GL_VERSION: 3.0 Mesa 8.0.2 (git-54f7391) GL_VENDOR: Tungsten Graphics, Inc GL_RENDERER: Mesa DRI Intel(R) Sandybridge Desktop GL_VERSION: 3.0 Mesa 8.0.2 (git-54f7391) +++ Besides an upcoming AWT Threading cleanup which resulted during bug analysis - no JOGL changes will happen until the bug can be reproduced with an own build .. Any volunteers to help / reproduce ? *** Bug 568 has been marked as a duplicate of this bug. *** Validation of Mesa 8.0.2 on ArchLinux (see Bug #568) .. works out of the box. Stats: - Manual compiled Mesa (8.0 and 8.1-dev [master]) works - ArchLinux Mesa 8.0.2 works Hence the ppa (?) packaging or patches of Mesa 8.0.X must be buggy. Further triage: Bisecting Ubuntu Mesa8 patches. - Freeze: Reproduced on Ubuntu 12.04 w/ deb. package sources, incl. all [debian/ubuntu] patches. - OK: Building original Mesa 8.0.2 (w/o patches) patches/series ++++ 02_use-ieee-fp-on-s390-and-m68k.patch 04_osmesa_version.diff 05_kfreebsd-egl-x11.diff 06_kfreebsd-ftbfs.diff 08-kfreebsd-gallium.diff 10-hurd-configure-tweaks.diff #11-hurd-ftbfs-again.diff 13-llvm-config-pick-a-version.diff # Ubuntu patches. 100_no_abi_tag.patch 101_ubuntu_hidden_glname.patch 113_fix_tls.diff 115_llvm_dynamic_linking.diff 116_use_shared_galliumcore.diff 117_intel_fix_hiz_null_dereference.patch +++ - GOOD: Building original Mesa 8.0.2 + patched 02, 04, 05, 06, 08, 10, 13 - GOOD: Building original Mesa 8.0.2 + patched 02, 04, 05, 06, 08, 10, 13, 100, 101 - FREEZE: Building original Mesa 8.0.2 + patched 02, 04, 05, 06, 08, 10, 13, 100, 101, 113 Offending patch: 113_fix_tls.diff ===================== Analysis of patch 113_fix_tls.diff and it's freezing impact:
+++
extern __thread void *u_current_user
- __attribute__((tls_model("initial-exec")));
+ __attribute__((tls_model("global-dynamic")));
+++
the above changes the TLS behavior of libGL.
Note: u_current_user reflects the current context
changed by glXMakeContextCurrent(..).
Phenomenon of AWT-EDT glXMakeContextCurrent() freeze:
[0] Java launches
[0.1] starts new AWT-EDT thread
[0.2] starts main thread and hands over execution of main
[1] JOGL initializes the libGL via 1st call of GLProfile.initSingleton()
incl. lib loading via dlopen() and symbol lookup etc.
[2] Step [1] kicks of the shared resource runner, which creates the very 1st JOGL GL context
while probing all profiles.
[3] At some point, AWT-EDT runs a JOGL Runnable:
[3.1] ctx = createContext()
[3.2] makeCurrent(dpy, read, write, ctx);
[3.3] makeCurrent(dpy, 0, 0, 0); -> release context *** Freeze ***
glx/glxcurrent.c/MakeContextCurrent():............__glXSetCurrentContextNull()
glx/glxcurrent.c/__glXSetCurrentContextNull(): .......... _glapi_set_context(NULL);
./mapi/mapi/mapi_glapi.c/_glapi_set_context(NULL): ........u_current_set_user(NULL);
./mapi/mapi/u_current.c/u_current_set_user(NULL): .............u_current_init();
./mapi/mapi/u_current.c/u_current_set_user(NULL): .............u_current_user = (void *) ptr; ***** FREEZE ***
Mesa8 release-context implementation attempts to access the TLS u_current_user 'field'.
For some reason, an already existing thread like AWT-EDT [0.1] cannot use libGL's global TLS [3]
when the latter was initialized by a later running thread [0.2] + [1].
Prove that this is the root cause can be made by it's remedies:
R1: Set java system property 'sun.java2d.opengl' to 'true', which loads and uses libGL from the start.
R2: Run GLProfile.initSingleton() [1] from the AWT-EDT
+++
R2 will be our workaround in JOGL.
+++
Nevertheless, it is unclear whether the above behavior is intrinsic to
tls_model("global-dynamic") and hence a restriction or other special circumstances
lead to an erroneous behavior.
Note:tls_model("initial-exec") works fine, i.e. w/o patch 113_fix_tls.diff
gluegen commit 1c03dfd6d1939a46018583419956e350e531f4fe
+++
DynamicLibraryBundle*: Allow DynamicLibraryBundleInfo impl. to designate a thread to load native libraries. (Fix Bug 566)
Due to requirements of native libraries using tls_model("global-dynamic")
a thread can be designated to load the 'tool' native libraries.
In case the tool lib uses tls_model("global-dynamic"),
an implementation shall try to let the early most thread load it.
For example, AWT-EDT shall load Mesa8 (Ubuntu-TLS) libGL.so.1
+++
I am reopening this bug: The gluegen workaround in #14 only half fix this bug: I am able to reproduce this bug using Ubuntu 11.10 using mesa 7.11 GL_VENDOR: X.Org GL_RENDERER: Gallium 0.4 on AMD RV770 GL_VERSION: 2.1 Mesa 7.11 Testcase wget http://processing.googlecode.com/files/processing-2.0a5-linux.tgz tar zxvf processing-2.0a5-linux.tgz cd processing-2.0a5 ./processing #open File->Examples... Pick Topics->Geometry-> double click on RGBCube #run the sketch ctrl-r #output below: xranby@hp ~/processing-2.0a5 $ ./processing Info: XInitThreads() called for concurrent Thread support <freeze> xranby@hp ~/processing-2.0a5+gluegen pr566fix $ ./processing Info: XInitThreads() called for concurrent Thread support Smooth level 2 is not supported by the hardware. Using 0 instead. <freeze> Now when testing using the -Dsun.java2d.opengl=True workaround, mentioned above, to change the init order: gedit ~/.processing/preferences.txt #and set run.options=-Dsun.java2d.opengl=True xranby@hp ~/processing-2.0a5 $ ./processing OpenGL pipeline enabled for default config on screen 0 Info: XInitThreads() called for concurrent Thread support Smooth level 2 is not supported by the hardware. Using 0 instead. <code are running> xranby@hp ~/processing-2.0a5+gluegen pr566fix $ ./processing OpenGL pipeline enabled for default config on screen 0 Info: XInitThreads() called for concurrent Thread support Smooth level 2 is not supported by the hardware. Using 0 instead. <code are running> (In reply to comment #15) > I am reopening this bug: > The gluegen workaround in #14 only half fix this bug: > > I am able to reproduce this bug using Ubuntu 11.10 using mesa 7.11 > GL_VENDOR: X.Org > GL_RENDERER: Gallium 0.4 on AMD RV770 > GL_VERSION: 2.1 Mesa 7.11 > Works here w/ the workaround on Ubuntu 12.04 and their Mesa8 package installed. Xerxes added a bug report for Mesa(Ubuntu): https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/965798 Processing 2.0 users are hitting this bug frequently: http://code.google.com/p/processing/issues/detail?id=1026 https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/965798 This bug was fixed in the package mesa - 8.0.2-0ubuntu3 for Ubuntu 12.04 --------------- mesa (8.0.2-0ubuntu3) precise; urgency=low * Drop 113_fix_tls.diff - this turns out to have been working around a libc bug (most likely Debian bug #637239) which is now fixed. It also seems to be causing problems itself now. (LP: #965798) -- Christopher James Halse Rogers <raof@ubuntu.com> Tue, 27 Mar 2012 12:51:58 +1100 ** Changed in: mesa (Ubuntu) Status: Confirmed => Fix Released It looks like scilab users have been hitting this bug as well (for a while now) https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/877491 For curiosity, is there a way to tackle the bug from an application itself ? (ie without having to wait the new mesa packages ?) thanks |
Created attachment 341 [details] Output of the OpenGL gears unit test When adding a GLCanvas, GLJPanel to a Frame, JFrame, the application freezes (no reaction to user input) and only a blank window is shown. The application cannot be terminated in a usual way but needs to be killed using killall -9. The OpenGL Gears unit test (invoked using java -Dsun.java2d.noddraw=true -Dsun.java2d.opengl=false -Djava.library.path=lib -Djogamp.debug=all -Dnativewindow.debug=all -Djogl.debug=all -Dnewt.debug=all -classpath jar/gluegen-rt.jar:jar/jogl.all.jar:jar/jogl.test.jar:jar/junit.jar:jar/junit-4.10.jar com.jogamp.opengl.test.junit.jogl.demos.gl2.awt.TestGearsAWT) reveals the same problem (see attachment)