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)
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