Created attachment 358 [details] wade walker project code Last I checked, this code from Wade Walker's JOGL Eclipse RCP tutorial was working about 33% of the time and crashing the rest of the time (rough estimate). Now it seems to crash all the time. Eclipse 3.7.2 on Ubuntu 12.04. JOGL version: jogl-2.0-b762-20120619-linux-amd64 Eclipse: 3.7.2 OS: Linux 64 bit Ubuntu 12.04 Project export is attached. Here's the output in the console: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f98e3d8ae84, pid=4933, tid=140294638626560 # # JRE version: 6.0_24-b24 # Java VM: OpenJDK 64-Bit Server VM (20.0-b12 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea6 1.11.1 # Distribution: Ubuntu 12.04 LTS, package 6b24-1.11.1-4ubuntu3 # Problematic frame: # C [libpthread.so.0+0x9e84] pthread_mutex_lock+0x4 # # An error report file with more information is saved as: # /home/obscurite/hs_err_pid4933.log # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/ # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. #
See wade walker RCP JOGL tutorial here: http://wadeawalker.wordpress.com/2010/10/09/tutorial-a-cross-platform-workbench-program-using-java-opengl-and-eclipse/
I'll try this out and confirm it.
(In reply to comment #2) > I'll try this out and confirm it. Thanks. Have you had an opportunity to try this on Ubuntu 12.04/Eclipse 3.7.2 yet? -DP
(In reply to comment #3) Sorry, got real busy last week... should be able to do it Monday.
No worries. My schedule's insane too which is why my original reply took forever. In any case, I have some application ideas in mind that would use JOGL/RCP heavily, so I'll be relieved to find out what my problem is. It's probably something awfully dumb that I'm doing, but perhaps not. Thanks for your time and for your tutorial, which was so simple I could easily finish it in an evening. (In reply to comment #4) > Sorry, got real busy last week... should be able to do it Monday.
This appears to be some sort of problem with SWT and Ubuntu 12.04 (see attached dump file). Let me hunt around and see if there's something I can update in Eclipse or Ubuntu to fix this.
Created attachment 364 [details] Java HotSpot dump for error
I verified that the same problem shows up in Eclipse 4.2, so it's not something that gets fixed in Eclipse. I noticed that if you comment all the JOGL code out of the app, it comes up fine (though with no graphics), so there's definitely something JOGL is doing that causes this bug to be exposed. My current guess is that one of the background threads JOGL launches causes some sort of threading conflict when Eclipse later tries to render its window and hits the pthreads library when drawing text inside Pango/Cairo. Perhaps Sven could comment on the use of pthreads inside JOGL? The top of the stack looks like this: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libpthread.so.0+0x9e84] pthread_mutex_lock+0x4 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.eclipse.swt.internal.gtk.OS._pango_cairo_show_layout(JJ)V+0 j org.eclipse.swt.internal.gtk.OS.pango_cairo_show_layout(JJ)V+9 j org.eclipse.swt.graphics.GC.drawText(Ljava/lang/String;III)V+280 j org.eclipse.swt.custom.CTabFolderRenderer.drawSelected(ILorg/eclipse/swt/graphics/GC;Lorg/eclipse/swt/graphics/Rectangle;I)V+2155 j org.eclipse.swt.custom.CTabFolderRenderer.draw(IILorg/eclipse/swt/graphics/Rectangle;Lorg/eclipse/swt/graphics/GC;)V+152 j org.eclipse.swt.custom.CTabFolder.onPaint(Lorg/eclipse/swt/widgets/Event;)V+316 j org.eclipse.swt.custom.CTabFolder$1.handleEvent(Lorg/eclipse/swt/widgets/Event;)V+285 j org.eclipse.swt.widgets.EventTable.sendEvent(Lorg/eclipse/swt/widgets/Event;)V+214 j org.eclipse.swt.widgets.Widget.sendEvent(Lorg/eclipse/swt/widgets/Event;)V+25 j org.eclipse.swt.widgets.Widget.sendEvent(ILorg/eclipse/swt/widgets/Event;Z)V+73 j org.eclipse.swt.widgets.Widget.sendEvent(ILorg/eclipse/swt/widgets/Event;)V+4 j org.eclipse.swt.widgets.Control.gtk_expose_event(JJ)J+179 j org.eclipse.swt.widgets.Composite.gtk_expose_event(JJ)J+42 j org.eclipse.swt.widgets.Widget.windowProc(JJJ)J+392 j org.eclipse.swt.widgets.Control.windowProc(JJJ)J+327 j org.eclipse.swt.widgets.Display.windowProc(JJJ)J+20
This is exciting progress, thanks for the updates. I look forward to being able to run JOGL code. DP (In reply to comment #8) > I verified that the same problem shows up in Eclipse 4.2, so it's not something > that gets fixed in Eclipse. > > I noticed that if you comment all the JOGL code out of the app, it comes up > fine (though with no graphics), so there's definitely something JOGL is doing > that causes this bug to be exposed. > > My current guess is that one of the background threads JOGL launches causes > some sort of threading conflict when Eclipse later tries to render its window > and hits the pthreads library when drawing text inside Pango/Cairo. > > Perhaps Sven could comment on the use of pthreads inside JOGL? The top of the > stack looks like this: > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0x9e84] pthread_mutex_lock+0x4 > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j org.eclipse.swt.internal.gtk.OS._pango_cairo_show_layout(JJ)V+0 > j org.eclipse.swt.internal.gtk.OS.pango_cairo_show_layout(JJ)V+9 > j org.eclipse.swt.graphics.GC.drawText(Ljava/lang/String;III)V+280 > j > org.eclipse.swt.custom.CTabFolderRenderer.drawSelected(ILorg/eclipse/swt/graphics/GC;Lorg/eclipse/swt/graphics/Rectangle;I)V+2155 > j > org.eclipse.swt.custom.CTabFolderRenderer.draw(IILorg/eclipse/swt/graphics/Rectangle;Lorg/eclipse/swt/graphics/GC;)V+152 > j > org.eclipse.swt.custom.CTabFolder.onPaint(Lorg/eclipse/swt/widgets/Event;)V+316 > j > org.eclipse.swt.custom.CTabFolder$1.handleEvent(Lorg/eclipse/swt/widgets/Event;)V+285 > j > org.eclipse.swt.widgets.EventTable.sendEvent(Lorg/eclipse/swt/widgets/Event;)V+214 > j > org.eclipse.swt.widgets.Widget.sendEvent(Lorg/eclipse/swt/widgets/Event;)V+25 > j > org.eclipse.swt.widgets.Widget.sendEvent(ILorg/eclipse/swt/widgets/Event;Z)V+73 > j > org.eclipse.swt.widgets.Widget.sendEvent(ILorg/eclipse/swt/widgets/Event;)V+4 > j org.eclipse.swt.widgets.Control.gtk_expose_event(JJ)J+179 > j org.eclipse.swt.widgets.Composite.gtk_expose_event(JJ)J+42 > j org.eclipse.swt.widgets.Widget.windowProc(JJJ)J+392 > j org.eclipse.swt.widgets.Control.windowProc(JJJ)J+327 > j org.eclipse.swt.widgets.Display.windowProc(JJJ)J+20
Anything I can do to help? Thanks for your efforts. DP > My current guess is that one of the background threads JOGL launches causes > some sort of threading conflict when Eclipse later tries to render its window > and hits the pthreads library when drawing text inside Pango/Cairo. > > Perhaps Sven could comment on the use of pthreads inside JOGL? The top of the > stack looks like this:
I've tried JOGL versions back to the beginning of 2011 to see if this was a JOGL regression, and it doesn't seem to be -- JOGL as far back as 1/20/2011 gives the identical error. I've also looked in the JOGL source for pthreads code, and it only seems to occur in some native Mac windowing code, so we're not calling it directly in this case. However, we do call XInitThreads() and other Xlib functions, which can cause this sort of problem in interactions between threads of a multithreaded program. I'm investigating this possibility further now.
Feels like you're getting closer. I'll buy you a virtual beer when this is all over. > However, we do call XInitThreads() and other Xlib functions, which can cause > this sort of problem in interactions between threads of a multithreaded > program. I'm investigating this possibility further now.
(In reply to comment #11) > I've tried JOGL versions back to the beginning of 2011 to see if this was a > JOGL regression, and it doesn't seem to be -- JOGL as far back as 1/20/2011 > gives the identical error. > > I've also looked in the JOGL source for pthreads code, and it only seems to > occur in some native Mac windowing code, so we're not calling it directly in > this case. > > However, we do call XInitThreads() and other Xlib functions, which can cause > this sort of problem in interactions between threads of a multithreaded > program. I'm investigating this possibility further now. sorry Wade .. I was trying to push all the features in, even SWT: https://jogamp.org/chuck/view/fwd/job/jogl/785/ (see forum email ..) .. my bad, lack of communication. Yes, the pthread stuff is AFAIK only required on OSX .. but I would need to grep for it in sources. I dl your code, but had no time to test :( If it's SWT related .. hopefully the new SWT code will fix lots of things .. dunno. See you later in LA .. in a few ..
I've experienced the same bug with our jogl/rcp application, but only under certain conditions: 1) Using the exported project - starting from Eclipse works as expected 2) Only in a specifc way of starting our application (with a project as command line argument) It crashes exactly when jogl is about to start rendering. My Platform is Kubuntu 12.04, 64 bit # SIGSEGV (0xb) at pc=0x00007f4dbbbade84, pid=7273, tid=139971816969984 # # JRE version: 6.0_26-b03 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libpthread.so.0+0x9e84] pthread_mutex_lock+0x4 #
Glad to see some movement on this. We are running into the same problems. I posted some info in the forums where Wade was kind enough to look into the problem, but will place the info here in case it helps with some resolution. For what it's worth: We notice that if an OpenGL window is not part of the initial opened perspective we don't have any problems (no problems on initializing a GL window after the app fully starts). It seems to only occur when the GL_Canvas tries to initialize with competing SWT views. We are finding that the application does one of three things: 1) The pthread error as described or 2) The app hangs on window initialization or 3) The app launches and behaves perfectly fine from there on out. For what it's worth we are using the AWT_SWT method posted in Wade's tutorial, with the 2.0rc8 build under both 3.6 and 3.7 target platforms using Oracle Java 1.6 and 1.7. We are producing builds on Windows 32 & 64, Mac, and Linux 32 & 64. We are only seeing the error on Linux 32 & 64. We've tested against Ubuntu 10.10 and 12.04, CentOS and Redhat.
I don't reproduce this bug under Cent OS 5.3. I use one of my tricks, I provided some source code in another bug report: https://jogamp.org/bugzilla/show_bug.cgi?id=455 Look at the class DummyRCPViewer3D.
(In reply to comment #16) > I don't reproduce this bug under Cent OS 5.3. I use one of my tricks, I > provided some source code in another bug report: > https://jogamp.org/bugzilla/show_bug.cgi?id=455 > > Look at the class DummyRCPViewer3D. Hi Julien, Did you try running the original demo code? Can you pinpoint why your code works but the demo doesn't? Can you let us know your version of SWT and Eclipse? Thank you. DP
(In reply to comment #17) > (In reply to comment #16) > > I don't reproduce this bug under Cent OS 5.3. I use one of my tricks, I > > provided some source code in another bug report: > > https://jogamp.org/bugzilla/show_bug.cgi?id=455 > > > > Look at the class DummyRCPViewer3D. > > Hi Julien, > > Did you try running the original demo code? Can you pinpoint why your code > works but the demo doesn't? Can you let us know your version of SWT and > Eclipse? > > Thank you. > > DP Hi I don't need to run the demo code, it is a dead end. At first, mixing JOGL 2.0 with Eclipse SWT OpenGL canvas instead of using one of JOGL canvases is a bad idea, Eclipse SWT OpenGL API has not been maintained since 2006 and it is quite "common" to get crashes especially with certain values in GLCapabilities. Secondly, my source code just does the right thing with the SWT AWT bridge and uses the AWT heavyweight GLCanvas (from JOGL), it doesn't fail to support TraceGL and DebugGL (but we currently use NewtCanvasAWT). Using abandonned APIs in industrial projects is a complete nonsense. Please try to reproduce your bug with an example using only JOGL 2.0 for the OpenGL rendering and for the canvas, it may confirm that the problem comes from SWT and Unity (window manager used under Ubuntu). I use Eclipse 3.7.2 under Cent OS Linux 5.3, Intel 64 bits, OpenJDK 1.6, Oracle JDK 1.6 update 33 and Oracle JDK 1.7 update 3, Nvidia Quadro 2000 (proprietary driver version 304.37).
I tried Julien's code, but the view fails entirely. !SESSION 2012-08-22 15:48:08.728 ----------------------------------------------- eclipse.buildId=I20120608-1400 java.version=1.6.0_26 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Framework arguments: -product org.eclipse.platform.ide Command-line arguments: -product org.eclipse.platform.ide -data /home/bforrester/Development/workspace-tempopengl/../runtime-EclipseApplication -dev file:/home/bforrester/Development/workspace-tempopengl/.metadata/.plugins/org.eclipse.pde.core/Eclipse Application/dev.properties -os linux -ws gtk -arch x86_64 -consoleLog !ENTRY com.src.ewir.logging.uncaughtexceptionhandlerimpl.LoggingUncaughtExceptionHandler 4 0 2012-08-22 15:48:16.765 !MESSAGE Uncaught Thread Exception in: "AWT-EventQueue-0-AWTAnimator-1" !STACK 0 java.lang.RuntimeException: javax.media.opengl.GLException: AWT-EventQueue-0: Error making temp context(1) current: display 0x7fe7fd277900, context 0x7fe80b5737e8, drawable X11OnscreenGLXDrawable[Realized true, Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@27743073, handle 0x6600026, Window JAWT-Window[windowHandle 0x6600026, surfaceHandle 0x6600026, bounds [ 0 / 0 575 x 291 ], insets [ l 0, r 0 - t 0, b 0 - 0x0], shallUseOffscreenLayer false, isOffscreenLayerSurface false, pos 0/0, size 575x291, visible true, lockedExt false, config AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type AWT, connection :0.0, unitID 0, awtDevice X11GraphicsDevice[screen=0], handle 0x0], idx 0], chosen GLCaps[glx vid 0x2f, fbc 0x8d: on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x2f], encapsulated X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type X11, connection :0.0, unitID 0, handle 0x7fe7fd277900], idx 0], visualID 0x30, fbConfigID 0x8f, requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], chosen GLCaps[glx vid 0x30, fbc 0x8f: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]]]], awtComponent AWT-GLCanvas[Realized true, jogamp.opengl.x11.glx.X11OnscreenGLXDrawable, Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@27743073, handle 0x6600026, Drawable size 575x291, AWT pos 0/0, size 575x291, visible true, AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type AWT, connection :0.0, unitID 0, awtDevice X11GraphicsDevice[screen=0], handle 0x0], idx 0], chosen GLCaps[glx vid 0x2f, fbc 0x8d: on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x2f], encapsulated X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type X11, connection :0.0, unitID 0, handle 0x7fe7fd277900], idx 0], visualID 0x30, fbConfigID 0x8f, requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], chosen GLCaps[glx vid 0x30, fbc 0x8f: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]]]]], surfaceLock <3d18e241, 2cae38bd>[count 1, qsz 0, owner <AWT-EventQueue-0>]]] at jogamp.common.awt.AWTEDTExecutor.invoke(AWTEDTExecutor.java:58) at jogamp.opengl.awt.AWTThreadingPlugin.invokeOnOpenGLThread(AWTThreadingPlugin.java:103) at jogamp.opengl.ThreadingImpl.invokeOnOpenGLThread(ThreadingImpl.java:206) at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:172) at javax.media.opengl.Threading.invoke(Threading.java:191) at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:405) at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:74) at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:142) at com.jogamp.opengl.util.Animator$MainLoop.run(Animator.java:176) at java.lang.Thread.run(Thread.java:662) Caused by: javax.media.opengl.GLException: AWT-EventQueue-0: Error making temp context(1) current: display 0x7fe7fd277900, context 0x7fe80b5737e8, drawable X11OnscreenGLXDrawable[Realized true, Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@27743073, handle 0x6600026, Window JAWT-Window[windowHandle 0x6600026, surfaceHandle 0x6600026, bounds [ 0 / 0 575 x 291 ], insets [ l 0, r 0 - t 0, b 0 - 0x0], shallUseOffscreenLayer false, isOffscreenLayerSurface false, pos 0/0, size 575x291, visible true, lockedExt false, config AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type AWT, connection :0.0, unitID 0, awtDevice X11GraphicsDevice[screen=0], handle 0x0], idx 0], chosen GLCaps[glx vid 0x2f, fbc 0x8d: on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x2f], encapsulated X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type X11, connection :0.0, unitID 0, handle 0x7fe7fd277900], idx 0], visualID 0x30, fbConfigID 0x8f, requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], chosen GLCaps[glx vid 0x30, fbc 0x8f: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]]]], awtComponent AWT-GLCanvas[Realized true, jogamp.opengl.x11.glx.X11OnscreenGLXDrawable, Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@27743073, handle 0x6600026, Drawable size 575x291, AWT pos 0/0, size 575x291, visible true, AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type AWT, connection :0.0, unitID 0, awtDevice X11GraphicsDevice[screen=0], handle 0x0], idx 0], chosen GLCaps[glx vid 0x2f, fbc 0x8d: on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x2f], encapsulated X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type X11, connection :0.0, unitID 0, handle 0x7fe7fd277900], idx 0], visualID 0x30, fbConfigID 0x8f, requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], chosen GLCaps[glx vid 0x30, fbc 0x8f: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]]]]], surfaceLock <3d18e241, 2cae38bd>[count 1, qsz 0, owner <AWT-EventQueue-0>]]] at jogamp.opengl.x11.glx.X11GLXContext.createImplRaw(X11GLXContext.java:328) at jogamp.opengl.x11.glx.X11GLXContext.createImpl(X11GLXContext.java:260) at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:505) at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:424) at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:415) at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:364) at javax.media.opengl.awt.GLCanvas$8.run(GLCanvas.java:864) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:641) at java.awt.EventQueue.access$000(EventQueue.java:84) at java.awt.EventQueue$1.run(EventQueue.java:602) at java.awt.EventQueue$1.run(EventQueue.java:600) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87) at java.awt.EventQueue.dispatchEvent(EventQueue.java:611) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) !ENTRY com.src.ewir.logging.uncaughtexceptionhandlerimpl.LoggingUncaughtExceptionHandler 4 0 2012-08-22 15:48:16.796 !MESSAGE Uncaught Thread Exception in: "AWT-EventQueue-0" !STACK 0 javax.media.opengl.GLException: AWT-EventQueue-0: Error making temp context(1) current: display 0x7fe7fd277900, context 0x7fe80b586d98, drawable X11OnscreenGLXDrawable[Realized true, Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@27743073, handle 0x6600026, Window JAWT-Window[windowHandle 0x6600026, surfaceHandle 0x6600026, bounds [ 0 / 0 575 x 291 ], insets [ l 0, r 0 - t 0, b 0 - 0x0], shallUseOffscreenLayer false, isOffscreenLayerSurface false, pos 0/0, size 575x291, visible true, lockedExt false, config AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type AWT, connection :0.0, unitID 0, awtDevice X11GraphicsDevice[screen=0], handle 0x0], idx 0], chosen GLCaps[glx vid 0x2f, fbc 0x8d: on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x2f], encapsulated X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type X11, connection :0.0, unitID 0, handle 0x7fe7fd277900], idx 0], visualID 0x30, fbConfigID 0x8f, requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], chosen GLCaps[glx vid 0x30, fbc 0x8f: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]]]], awtComponent AWT-GLCanvas[Realized true, jogamp.opengl.x11.glx.X11OnscreenGLXDrawable, Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@27743073, handle 0x6600026, Drawable size 575x291, AWT pos 0/0, size 575x291, visible true, AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type AWT, connection :0.0, unitID 0, awtDevice X11GraphicsDevice[screen=0], handle 0x0], idx 0], chosen GLCaps[glx vid 0x2f, fbc 0x8d: on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x2f], encapsulated X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type X11, connection :0.0, unitID 0, handle 0x7fe7fd277900], idx 0], visualID 0x30, fbConfigID 0x8f, requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], chosen GLCaps[glx vid 0x30, fbc 0x8f: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]]]]], surfaceLock <3d18e241, 2cae38bd>[count 1, qsz 0, owner <AWT-EventQueue-0>]]] at jogamp.opengl.x11.glx.X11GLXContext.createImplRaw(X11GLXContext.java:328) at jogamp.opengl.x11.glx.X11GLXContext.createImpl(X11GLXContext.java:260) at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:505) at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:424) at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:415) at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:364) at javax.media.opengl.awt.GLCanvas$8.run(GLCanvas.java:864) at javax.media.opengl.Threading.invoke(Threading.java:193) at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:405) at javax.media.opengl.awt.GLCanvas.paint(GLCanvas.java:482) at sun.awt.RepaintArea.paintComponent(RepaintArea.java:248) at sun.awt.X11.XRepaintArea.paintComponent(XRepaintArea.java:56) at sun.awt.RepaintArea.paint(RepaintArea.java:224) at sun.awt.X11.XComponentPeer.handleEvent(XComponentPeer.java:695) at java.awt.Component.dispatchEventImpl(Component.java:4727) at java.awt.Component.dispatchEvent(Component.java:4481) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:643) at java.awt.EventQueue.access$000(EventQueue.java:84) at java.awt.EventQueue$1.run(EventQueue.java:602) at java.awt.EventQueue$1.run(EventQueue.java:600) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98) at java.awt.EventQueue$2.run(EventQueue.java:616) at java.awt.EventQueue$2.run(EventQueue.java:614) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87) at java.awt.EventQueue.dispatchEvent(EventQueue.java:613) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) !ENTRY com.src.ewir.logging.uncaughtexceptionhandlerimpl.LoggingUncaughtExceptionHandler 4 0 2012-08-22 15:48:17.007 !MESSAGE Uncaught Thread Exception in: "AWT-EventQueue-0" !STACK 0 javax.media.opengl.GLException: AWT-EventQueue-0: Error making temp context(1) current: display 0x7fe7fd277900, context 0x7fe7fde43b28, drawable X11OnscreenGLXDrawable[Realized true, Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@27743073, handle 0x6600026, Window JAWT-Window[windowHandle 0x6600026, surfaceHandle 0x6600026, bounds [ 0 / 0 916 x 402 ], insets [ l 0, r 0 - t 0, b 0 - 0x0], shallUseOffscreenLayer false, isOffscreenLayerSurface false, pos 0/0, size 916x402, visible true, lockedExt false, config AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type AWT, connection :0.0, unitID 0, awtDevice X11GraphicsDevice[screen=0], handle 0x0], idx 0], chosen GLCaps[glx vid 0x2f, fbc 0x8d: on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x2f], encapsulated X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type X11, connection :0.0, unitID 0, handle 0x7fe7fd277900], idx 0], visualID 0x30, fbConfigID 0x8f, requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], chosen GLCaps[glx vid 0x30, fbc 0x8f: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]]]], awtComponent AWT-GLCanvas[Realized true, jogamp.opengl.x11.glx.X11OnscreenGLXDrawable, Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@27743073, handle 0x6600026, Drawable size 916x402, AWT pos 0/0, size 916x402, visible true, AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type AWT, connection :0.0, unitID 0, awtDevice X11GraphicsDevice[screen=0], handle 0x0], idx 0], chosen GLCaps[glx vid 0x2f, fbc 0x8d: on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x2f], encapsulated X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type X11, connection :0.0, unitID 0, handle 0x7fe7fd277900], idx 0], visualID 0x30, fbConfigID 0x8f, requested GLCaps[on-scr, rgba 0x8/8/8/1, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/8, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]], chosen GLCaps[glx vid 0x30, fbc 0x8f: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/2, sample-ext default, dbl, mono , hw, GLProfile[GL3bc/GL3bc.hw]]]]], surfaceLock <3d18e241, 2cae38bd>[count 1, qsz 0, owner <AWT-EventQueue-0>]]] at jogamp.opengl.x11.glx.X11GLXContext.createImplRaw(X11GLXContext.java:328) at jogamp.opengl.x11.glx.X11GLXContext.createImpl(X11GLXContext.java:260) at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:505) at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:424) at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:415) at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:364) at javax.media.opengl.awt.GLCanvas$8.run(GLCanvas.java:864) at javax.media.opengl.Threading.invoke(Threading.java:193) at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:405) at javax.media.opengl.awt.GLCanvas.paint(GLCanvas.java:482) at sun.awt.RepaintArea.paintComponent(RepaintArea.java:248) at sun.awt.X11.XRepaintArea.paintComponent(XRepaintArea.java:56) at sun.awt.RepaintArea.paint(RepaintArea.java:224) at sun.awt.X11.XComponentPeer.handleEvent(XComponentPeer.java:695) at java.awt.Component.dispatchEventImpl(Component.java:4727) at java.awt.Component.dispatchEvent(Component.java:4481) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:643) at java.awt.EventQueue.access$000(EventQueue.java:84) at java.awt.EventQueue$1.run(EventQueue.java:602) at java.awt.EventQueue$1.run(EventQueue.java:600) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98) at java.awt.EventQueue$2.run(EventQueue.java:616) at java.awt.EventQueue$2.run(EventQueue.java:614) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87) at java.awt.EventQueue.dispatchEvent(EventQueue.java:613) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Disregard.. I must have had an incompatible initialization with setNumSamples and setSampleBuffers. The view is working now - I will try to reproduce the threading errors with this implementation...
(In reply to comment #20) > Disregard.. I must have had an incompatible initialization with setNumSamples > and setSampleBuffers. The view is working now - I will try to reproduce the > threading errors with this implementation... Can you be more precise please? Which modification causes the crash of my example?
(In reply to comment #19) > I tried Julien's code, but the view fails entirely. > > !SESSION 2012-08-22 15:48:08.728 > ----------------------------------------------- > eclipse.buildId=I20120608-1400 > java.version=1.6.0_26 > java.vendor=Sun Microsystems Inc. > BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US > Framework arguments: -product org.eclipse.platform.ide > Command-line arguments: -product org.eclipse.platform.ide -data > /home/bforrester/Development/workspace-tempopengl/../runtime-EclipseApplication > -dev > file:/home/bforrester/Development/workspace-tempopengl/.metadata/.plugins/org.eclipse.pde.core/Eclipse > Application/dev.properties -os linux -ws gtk -arch x86_64 -consoleLog > > !ENTRY > com.src.ewir.logging.uncaughtexceptionhandlerimpl.LoggingUncaughtExceptionHandler > 4 0 2012-08-22 15:48:16.765 > !MESSAGE Uncaught Thread Exception in: "AWT-EventQueue-0-AWTAnimator-1" > !STACK 0 > java.lang.RuntimeException: javax.media.opengl.GLException: AWT-EventQueue-0: > Error making temp context(1) current: display 0x7fe7fd277900, context > 0x7fe80b5737e8, drawable X11OnscreenGLXDrawable[Realized true, > Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@27743073, > handle 0x6600026, > Window JAWT-Window[windowHandle 0x6600026, surfaceHandle 0x6600026, This kind of error occurs when you don't use the same thread to create the OpenGL context and to make it current during the rendering, it doesn't come from my source code.
(In reply to comment #21) > (In reply to comment #20) > > Disregard.. I must have had an incompatible initialization with setNumSamples > > and setSampleBuffers. The view is working now - I will try to reproduce the > > threading errors with this implementation... > > Can you be more precise please? Which modification causes the crash of my > example? I had to comment out glCapabilities.setNumSamples(8); - I guess my hardware didn't support it.
(In reply to comment #23) > (In reply to comment #21) > > (In reply to comment #20) > > > Disregard.. I must have had an incompatible initialization with setNumSamples > > > and setSampleBuffers. The view is working now - I will try to reproduce the > > > threading errors with this implementation... > > > > Can you be more precise please? Which modification causes the crash of my > > example? > > I had to comment out glCapabilities.setNumSamples(8); - I guess my hardware > didn't support it. Thanks. However, it should not cause such a crash, the chosen GLCapabilities object should just not keep this setting, there is something wrong in JOGL.
- First of all - don't use Eclipse's SWT GLCanvas! Please not the changes: <http://jogamp.org/git/?p=jogl.git;a=commit;h=7bb5885fc3a904f49e22f0c8cbf747d9b189a7ba> Our SWT GLCanvas has the restriction of: "Note: To employ custom GLCapabilities, NewtCanvasSWT shall be used instead." <http://jogamp.org/git/?p=jogl.git;a=blob;f=src/jogl/classes/com/jogamp/opengl/swt/GLCanvas.java;h=8d237162c018e9e44aee282a3f75672c83bf9ca7;hb=7bb5885fc3a904f49e22f0c8cbf747d9b189a7ba#l75> +++ If you like to use JOGL w/ restrictions (i.e. w/ your custom GLCapabilities) you have to use the new NewtCanvasSWT !!! Please check the new unit tests covering NewtCanvasSWT (within above commit). It's very similar (if not equal) of using NewtCanvasAWT. +++ Why can't you use custom GLCapabilities w/ our SWT GLCanvas ? Because at the time we instantiate it, it already _may_ have a native handle, read visual-id - which itself implies selected capabilities. +++
Created attachment 365 [details] Java HotSpot dump - gtk_main_do_event Added a HotSpot dump of our error since it appears to crash in a different routine than the one Wade posted.
We are not using SWT GLCanvas - we are using: javax.media.opengl.GL2; javax.media.opengl.GLAutoDrawable; javax.media.opengl.GLCapabilities; javax.media.opengl.GLEventListener; javax.media.opengl.GLProfile; javax.media.opengl.awt.GLCanvas; org.eclipse.swt.awt.SWT_AWT; So I tried replacing our existing OpenGL View in our application with the DummyRCPViewer3D as suggested but still get the threading error so it doesn't appear that Julien's workaround addresses our problem: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fd786cab634, pid=28376, tid=140563635025664 # # JRE version: 6.0_26-b03 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libpthread.so.0+0x9634] pthread_mutex_lock+0x4 # # An error report file with more information is saved as: # /home/bforrester/hs_err_pid28376.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # I'm adding a HotSpot dump because it is a bit different than what Wade previously posted...
This bug doesn't seem to have anything to do with the SWT canvas (or any other canvas). I've tried AWT, Swing GLCanvas, Swing GLJPanel, SWT, and the SWT-AWT bridge, and they all work fine for a simple one-triangle test on 64-bit Ubuntu 12.04 with Oracle Java 1.7.0_06. So it looks like it's the fact that the JOGL code is running from within Eclipse RCP that's causing the problem (presumably since JOGL isn't the first thing that runs, so the Linux X11 multithreading calls are messed up somehow). I'm trying to figure out how to make a standalone test case for this that I can hand to Sven, since the current test code has to be built from within Eclipse.
(In reply to comment #28) > This bug doesn't seem to have anything to do with the SWT canvas (or any other > canvas). I've tried AWT, Swing GLCanvas, Swing GLJPanel, SWT, and the SWT-AWT > bridge, and they all work fine for a simple one-triangle test on 64-bit Ubuntu > 12.04 with Oracle Java 1.7.0_06. > > So it looks like it's the fact that the JOGL code is running from within > Eclipse RCP that's causing the problem (presumably since JOGL isn't the first > thing that runs, so the Linux X11 multithreading calls are messed up somehow). > I'm trying to figure out how to make a standalone test case for this that I can > hand to Sven, since the current test code has to be built from within Eclipse. Is it reproducible only under Ubuntu?
(In reply to comment #29) > (In reply to comment #28) > > This bug doesn't seem to have anything to do with the SWT canvas (or any other > > canvas). I've tried AWT, Swing GLCanvas, Swing GLJPanel, SWT, and the SWT-AWT > > bridge, and they all work fine for a simple one-triangle test on 64-bit Ubuntu > > 12.04 with Oracle Java 1.7.0_06. > > > > So it looks like it's the fact that the JOGL code is running from within > > Eclipse RCP that's causing the problem (presumably since JOGL isn't the first > > thing that runs, so the Linux X11 multithreading calls are messed up somehow). > > I'm trying to figure out how to make a standalone test case for this that I can > > hand to Sven, since the current test code has to be built from within Eclipse. > > Is it reproducible only under Ubuntu? I just checked with our guys - I thought we had reproduced in CentOS but they said they couldn't get it to break in CentOS - It might just be Ubuntu but definitely NOT just Unity. We're seeing it with and without Unity - @Wade: did you test on any other distros of Linux?
(In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #28) > > > This bug doesn't seem to have anything to do with the SWT canvas (or any other > > > canvas). I've tried AWT, Swing GLCanvas, Swing GLJPanel, SWT, and the SWT-AWT > > > bridge, and they all work fine for a simple one-triangle test on 64-bit Ubuntu > > > 12.04 with Oracle Java 1.7.0_06. > > > > > > So it looks like it's the fact that the JOGL code is running from within > > > Eclipse RCP that's causing the problem (presumably since JOGL isn't the first > > > thing that runs, so the Linux X11 multithreading calls are messed up somehow). > > > I'm trying to figure out how to make a standalone test case for this that I can > > > hand to Sven, since the current test code has to be built from within Eclipse. > > > > Is it reproducible only under Ubuntu? > > I just checked with our guys - I thought we had reproduced in CentOS but they > said they couldn't get it to break in CentOS - It might just be Ubuntu but > definitely NOT just Unity. We're seeing it with and without Unity - I'm almost sure it was not broken in Ubuntu 11. Thank you for this information.
@Brandon: The demo worked on CentOS 5 (at least back when I originally tested it) -- that's the platform I developed it on. I never saw any problems until Ubuntu, but I didn't test on Ubuntu 11, just Ubuntu 12.
I've got it working now, but I need you guys to try this fix to confirm. Go to Activator.java in the tutorial code, and comment out the GLProfile.initSingleton() call near the top of this file. I've run it 20 times in a row now, in both debug and run modes, and it seems OK. My specs: - Ubuntu 12.04 - Java 1.7.0_06 - Latest code of JOGL, built by me on Ubuntu 12.04 - Eclipse Juno Note that in the comments above this function call, I say that this was put in originally to get rid of "SIGSEGV in libpthread.so (or other sorts of multithreading errors)". Hopefully we can remove this for all platforms now, since it's not supposed to be needed anymore. I tried this on CentOS 5.6, and it works there too.
(In reply to comment #33) > I've got it working now, but I need you guys to try this fix to confirm. Go to > Activator.java in the tutorial code, and comment out the > GLProfile.initSingleton() call near the top of this file. I've run it 20 times > in a row now, in both debug and run modes, and it seems OK. > > My specs: > > - Ubuntu 12.04 > - Java 1.7.0_06 > - Latest code of JOGL, built by me on Ubuntu 12.04 > - Eclipse Juno > > Note that in the comments above this function call, I say that this was put in > originally to get rid of "SIGSEGV in libpthread.so (or other sorts of > multithreading errors)". Hopefully we can remove this for all platforms now, > since it's not supposed to be needed anymore. I tried this on CentOS 5.6, and > it works there too. You can remove it in your case but it is still needed on some platforms when using the SWT/AWT bridge. For example, in my example, if you don't call it, you get a SIGSEGV under Ubuntu 12 whereas it is useless under Cent OS.
(In reply to comment #34) > You can remove it in your case but it is still needed on some platforms when > using the SWT/AWT bridge. For example, in my example, if you don't call it, you > get a SIGSEGV under Ubuntu 12 whereas it is useless under Cent OS. Well, I would like to see you test NewtCanvasSWT w/o the explicit GLProfile initialization. It should work fine IMHO. So .. I close this bug, unless you like to cont. triaging this (then pls reopen).
Re-opening this bug in discussion of the no_xinitthreads branch as discussed in the forum: <http://forum.jogamp.org/Turning-off-XInitThreads-tp4026119p4026209.html>
I have also added Bug 616 and made this depending on it, since it might be an X11 locking issue related to XInitThreads() .. Wade figure this IMHO w/ comment 33.
(In reply to comment #37) > I have also added Bug 616 > and made this depending on it, since it might be an X11 locking issue > related to XInitThreads() .. Wade figure this IMHO w/ comment 33. Ok but I will have to test it under Linux distros on which I needed to call initSingleton().
(In reply to comment #38) > (In reply to comment #37) > > I have also added Bug 616 > > and made this depending on it, since it might be an X11 locking issue > > related to XInitThreads() .. Wade figure this IMHO w/ comment 33. > > Ok but I will have to test it under Linux distros on which I needed to call > initSingleton(). Yes, pls do so w/ the x11_noxinitthreads branch and see if the 'requirement' (different behavior) goes away. would be great - thank you!
(In reply to comment #39) > (In reply to comment #38) > > (In reply to comment #37) > > > I have also added Bug 616 > > > and made this depending on it, since it might be an X11 locking issue > > > related to XInitThreads() .. Wade figure this IMHO w/ comment 33. > > > > Ok but I will have to test it under Linux distros on which I needed to call > > initSingleton(). > > Yes, pls do so w/ the x11_noxinitthreads branch and see if the 'requirement' > (different behavior) goes away. would be great - thank you! Ok. I think I needed to call this method with Cent OS Linux 5.3.
Fixed w/ remedy of Bug 616 and workaround of Bug 623.