Thanks Ken, that might give me a few more clues.

I speculatively removed a resize command and I've been doing a lot more testing and the errors aren't happening in the same way - a problem I've been bedeviled with.  In fact, bizarrely, there's been a reversal of fortunes with JOGL_SINGLE_THREADED_WORKAROUND; now when it's set I get no canvas on startup, when it's not set everything is fine.  I'm getting no errors in either situation and the hang on exit has disappeared.  When I move to another graphics card, or the ratio between the two canvas's startup times changes slightly, it'll all sod up in a slightly different way.  So I have zero confidence in the stability of my system and I was looking at this:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/ntopnglr_6flf.asp

and was wondering whether jogl was able to pass through that extended error information?

I'll stop it with the addendums soon but I do want to try and be accurate.  An additional effect of setting JOGL_SINGLE_THREADED_WORKAROUND is that the textures are correctly shared between the two canvases.  When it's not set, one window cannot see textures bound in another window, so to summarize:

When JOGL_SINGLE_THREADED_WORKAROUND=true there are no errors but no canvas is created on startup.  When canvas's are later created they are correctly shared.

When JOGL_SINGLE_THREADED_WORKAROUND=false there are errors, no canvas is created on startup, and when canvas's are later created texture sharing fails.

I just saw this line in the stack trace:

at net.java.games.jogl.GLCanvas.withSingleThreadedWorkaroundDo(GLCanvas.jav a:22

This trace was taken with no JOGL_SINGLE_THREADED_WORKAROUND set.  Odd?

I've tried the JOGL_SINGLE_THREADED_WORKAROUND with identical results as far as my app is concerned - i.e. the second window into which a canvas should have been placed remains blank, so it follows that no valid canvas was created as the original stack trace indicates.  The only difference is that no console output or error messages are produced.  I've also upgraded to the latest nvidia beta driver; that made no difference either.

I'm sure the assertion is real - questions are - what causes it and how can I avoid it?  It looks to me like the AssertionError is just down to some dodgy clean up code - the real culprit is the wglShareLists.  I certainly understand your desire for a simple test case but I don't think that's going to be possible - I'm dependent on about 20Mb of RCP and a ton of my own scaffolding for a start, and it only screws up one time in 5 here (although once it does screw up, it keeps on screwing up until the machine is rebooted).

I have "next" and "last" buttons in my app which runs the same code that fails on start up - it checks for a valid canvas and rendering thread and creates them if they don't exist.  During startup the wglShareLists call fails, but when I hit the next or last button it succeeds and the window bursts into glorious life.  So, Ken, what precondition am I not meeting on startup?  I can file a report if you'd still like me too - would you be able to paste a link to your issue tracking system?  For what it's worth, the full stack trace is below.

As an aside - I just saw the Linux thread and I'm getting hangs on exit on Windows too - thread lock problems I guess.  I have to use the eclipse debugger to break out of it.

Thanks for any help at all...
Henrietta


net.java.games.jogl.GLException: wglShareLists(0x10001, 0x10002) failed
     at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:161)
     at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:129)
     at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:246)
     at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:76)
     at net.java.games.jogl.GLCanvas.withSingleThreadedWorkaroundDo(GLCanvas.java:228)
     at net.java.games.jogl.GLCanvas.reshape(GLCanvas.java:125)
     at java.awt.Component.setBounds(Component.java:1847)
     at org.eclipse.ui.internal.PartPane$2.run(PartPane.java:148)
     at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044)
     at org.eclipse.core.runtime.Platform.run(Platform.java:747)
     at org.eclipse.ui.internal.PartPane.doCreateChildControl(PartPane.java:144)
     at org.eclipse.ui.internal.ViewPane.doCreateChildControl(ViewPane.java:135)
     at org.eclipse.ui.internal.PartPane.createChildControl(PartPane.java:349)
     at org.eclipse.ui.internal.ViewFactory$1.run(ViewFactory.java:398)
     at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044)
     at org.eclipse.core.runtime.Platform.run(Platform.java:747)
     at org.eclipse.ui.internal.ViewFactory.busyRestoreView(ViewFactory.java:287)
     at org.eclipse.ui.internal.ViewFactory$2.run(ViewFactory.java:582)
     at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
     at org.eclipse.ui.internal.ViewFactory.restoreView(ViewFactory.java:579)
     at org.eclipse.ui.internal.ViewFactory$ViewReference.getPart(ViewFactory.java:106)
     at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:329)
     at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:607)
     at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:126)
     at org.eclipse.ui.internal.presentations.newapi.PresentablePartFolder.select(PresentablePartFolder.java:266)
     at org.eclipse.ui.internal.presentations.newapi.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
     at org.eclipse.ui.internal.presentations.newapi.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:381)
     at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1034)
     at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:535)
     at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:472)
     at org.eclipse.ui.internal.PartSashContainer.createControl(PartSashContainer.java:477)
     at org.eclipse.ui.internal.PerspectiveHelper.activate(PerspectiveHelper.java:230)
     at org.eclipse.ui.internal.Perspective.onActivate(Perspective.java:779)
     at org.eclipse.ui.internal.WorkbenchPage.onActivate(WorkbenchPage.java:2028)
     at org.eclipse.ui.internal.WorkbenchWindow$4.run(WorkbenchWindow.java:2158)
     at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
     at org.eclipse.ui.internal.WorkbenchWindow.setActivePage(WorkbenchWindow.java:2144)
     at org.eclipse.ui.internal.WorkbenchWindow.restoreState(WorkbenchWindow.java:1676)
     at org.eclipse.ui.internal.Workbench.restoreState(Workbench.java:1414)
     at org.eclipse.ui.internal.Workbench.access$10(Workbench.java:1370)
     at org.eclipse.ui.internal.Workbench$15.run(Workbench.java:1273)
     at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044)
     at org.eclipse.core.runtime.Platform.run(Platform.java:747)
     at org.eclipse.ui.internal.Workbench.restoreState(Workbench.java:1207)
     at org.eclipse.ui.internal.WorkbenchConfigurer.restoreState(WorkbenchConfigurer.java:171)
     at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:659)
     at org.eclipse.ui.internal.Workbench.init(Workbench.java:886)
     at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1516)
     at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:285)
     at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:144)
     at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:220)
     at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273)
     at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:585)
     at org.eclipse.core.launcher.Main.basicRun(Main.java:185)
     at org.eclipse.core.launcher.Main.run(Main.java:710)
     at org.eclipse.core.launcher.Main.main(Main.java:694)
Exception in thread "AWT-EventQueue-0" java.lang.AssertionError: State of ShareSet corrupted; thought context net.java.games.jogl.impl.windows.WindowsOnscreenGLContext@1e940b should have been in created set but wasn't
     at net.java.games.jogl.impl.GLContextShareSet$ShareSet.contextDestroyed(GLContextShareSet.java:94)
     at net.java.games.jogl.impl.GLContextShareSet.contextDestroyed(GLContextShareSet.java:136)
     at net.java.games.jogl.impl.GLContext.destroy(GLContext.java:640)
     at net.java.games.jogl.GLCanvas.removeNotify(GLCanvas.java:98)
     at java.awt.Container.removeNotify(Container.java:2527)
     at java.awt.Frame.removeNotify(Frame.java:904)
     at java.awt.Window$1DisposeAction.run(Window.java:621)
     at java.awt.Window.doDispose(Window.java:633)
     at java.awt.Window.dispose(Window.java:588)
     at org.eclipse.swt.awt.SWT_AWT$6.run(SWT_AWT.java:213)
     at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
     at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
     at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
     at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Unhandled event loop exception
Reason:
State of ShareSet corrupted; thought context net.java.games.jogl.impl.windows.WindowsOnscreenGLContext@1e940b should have been in created set but wasn't

I'm running jogl within an Eclipse RCP environment with two GL canvasas which share their textures and display lists, and from time to time I get the error below and sometimes other errors about a GLContext.makeCurrent() failing.  It always works on ATI and fails occassionally on nvidia.  I've been fighting jogl multithreading issues and strange GLExceptions for months and thought for a while I had the problems conquered (mainly by delaying the first resize event for as long as possible after canvas creation).  I can't consistently reproduce these errors and a little test case is out of the question.  So can anybody shed any light on what's happening here?  Would it be possible for jogl to include more sanity checking and better error reporting in this area?

Internal error: Exception while resizing the editor
net.java.games.jogl.GLException: wglShareLists(0x10001, 0x10002) failed
     at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:156)
     at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)
     at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:250)
     at net.java.games.jogl.GLCanvas.reshape(GLCanvas.java:112)
     at java.awt.Component.setBounds(Component.java:1847)
     ...

// In 1.1b07 the rest of the error output is produced immediately upon startup,
// in 1.1b08 these remaining errors are printed when the application exits.

Exception in thread "AWT-EventQueue-0" java.lang.AssertionError: State of ShareSet corrupted; thought context net.java.games.jogl.impl.windows.WindowsOnscreenGLContext@6ffd79 should have been in created set but wasn't
     at net.java.games.jogl.impl.GLContextShareSet$ShareSet.contextDestroyed(GLContextShareSet.java:94)
     at net.java.games.jogl.impl.GLContextShareSet.contextDestroyed(GLContextShareSet.java:136)
     at net.java.games.jogl.impl.GLContext.destroy(GLContext.java:641)
     at net.java.games.jogl.GLCanvas.removeNotify(GLCanvas.java:96)
     at java.awt.Container.removeNotify(Container.java:2527)
     at java.awt.Frame.removeNotify(Frame.java:904)
     at java.awt.Window$1DisposeAction.run(Window.java:621)
     at java.awt.Window.doDispose(Window.java:633)
     at java.awt.Window.dispose(Window.java:588)
     at org.eclipse.swt.awt.SWT_AWT$6.run(SWT_AWT.java:213)
     at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
     ...

Unhandled event loop exception
Reason:
State of ShareSet corrupted; thought context net.java.games.jogl.impl.windows.WindowsOnscreenGLContext@6ffd79 should have been in created set but wasn't

Regards,
Henrietta

I may have fixed the problem, or at least significantly reduced the number of crashes.  I don't think that this error was multi-canvas related; it seemed more to do with the state of the window to which the new canvas was being attached.  When the component is attached a little later, it succeeds.

I'm still not sure why I have an intermittent glDrawElements() problem on ATI but I guess it could just as easily be within my own code or ATI's drivers.  I'll post more information when I have it.

I don't think I'm going to be able to boil this down to a simple test case, certainly not quickly.  I'm running the code within an Eclipse RCP app and the problem is timing sensitive so if I could reproduce it here, you might not be able to there.  BTW, I'm using Catalyst driver 6.14.10.6404, JDK 1.4.2_05 on Windows XP.

I would like to understand the threading model used in JOGL, so I'd be grateful if you could provide me with any more info on that, or point me in the direction of some documentation.  Are multi-threaded, multi-canvas apps supported by JOGL, at least in theory?  This startup message worries me: "Using ATI workaround of dispatching display() on event thread".  What was the original problem you were "working around"?

Is anybody else successfully writing multi-canvas jogl apps?  Is moving to LWJGL easy, and does it offer any more stability?

And if it is multiple canvas related, I've got another problem with maybe a similar explanation.  Once again, it's only intermittent and only on the ATI card.  I have a call to glDrawElements() that sometimes falls over with an access violation; I've written code to validate the integrity of my arrays on every render, and it always comes up OK.  So, hypothetically - if this were the problem and calls to glDrawElements() have to be thread synchronized, what else has to be too?

PS. I've got two GLCanvas's displayed when this problem occurs.

The only JOGL app I've tried is the one I'm developing and the fault is intermittant, failing about 20% of the time.  The ATI driver I'm using is marked 6.14.10.6404 which is in the latest Catalyst package.  Using DebugGL provides no additional info.

Hi, I'm running some code on 1.1 beta 5 which works fine on one machine with an NVidia card but fails on another with an ATI 7500 card with the error below.  Any idea what the error is, and whether this is a driver issue (I'm running the latest) or a timing or thread issue?

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x693B3A54
Function=DrvSetContext+0x12634
Library=C:\Windows\System32\atioglxx.dll

Current Java thread:
     at net.java.games.jogl.impl.windows.WGL.wglCreateContext(Native Method)
     at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:495)
     at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:211)
     at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:135)
     - locked <0x12ed7fb0> (a net.java.games.jogl.impl.windows.WindowsOnscreenGLContext)
     at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)
     - locked <0x12ed7fb0> (a net.java.games.jogl.impl.windows.WindowsOnscreenGLContext)
     at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:254)
     - locked <0x12ed7fb0> (a net.java.games.jogl.impl.windows.WindowsOnscreenGLContext)
     at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:208)
     at net.java.games.jogl.GLCanvas.display(GLCanvas.java:75)
     at net.java.games.jogl.GLCanvas.paint(GLCanvas.java:82)
     at sun.awt.RepaintArea.paint(RepaintArea.java:177)
     at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:260)
     at java.awt.Component.dispatchEventImpl(Component.java:3678)
     at java.awt.Component.dispatchEvent(Component.java:3477)
     at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
     at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
     at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

Another observation: when I used GKW's latest build to fix the sample buffer bug in 1b04 I got uncontrollable flicker on an ATI 7500.  Both this card and an NVidia 5950 were fine, in that repect, on all other builds.  I've had to go back to 1b03 for the moment.

I also use lit VBOs.

Nice work people - that fixed it.

Yep, I do:

capabilities.setNumSamples( 8 );
capabilities.setSampleBuffers( true );

And I keep everything the same between my 1b03 and 1b04 tests except for the jogl.jar, so that's where the problem is.

Interestingly the following line "glCanvas.setNoAutoRedrawMode( false )" has very occasionally made the 1b04 build work.  I read on another thread that the GLCanvas has to be attached to its frame only after the frame has been displayed and I wonder whether my problem has anything to do with that.  I certainly hope that that behavior is also considered a bug in jogl because I have no control over the state of the frame that is passed to me by the application framework I'm using.

Hi there, I've just upgraded from 1b03 to the 1b04 build and my DefaultGLCapabilitiesChooser now reports that I have no sample buffers - and I certainly don't seem to be able to use any - the call:

gl.glEnable( GL.GL_MULTISAMPLE_ARB );

consistently has no affect under 1b04 but consistently works with 1b03.

Do I need to change my code or this a bug in the new build?

Thanks

Excellent.  Thankyou.

I'm so glad you said that! I've been trying to figure out how to stripify on the fly from a z-sorted buffer.  Don't go there.

On a related note, any idea what's the best way to apply a different texture to each side of a triangle - do all of the triangle's vertices have to be specified twice with different texture coordinates each time?  Surely there's some way to cut down on that overhead?

Thanks.

Thanks Gregof; I think the extra two vertices in my 'strip stitch' are used for maintaining the correct winding order across strips.

The vertex array problem was a simple bug, and I fixed my filament problem by only smoothing polygons conditionally:

if ( GL_MULTISAMPLE_ARB is supported )
   gl.glEnable( GL.GL_POLYGON_SMOOTH );

Hi, I'm having a problem with glDrawElements.  I'm trying to render some triangle strips, which are stitched together with degenerate triangles into one very big strip.  That is, if I have a strip ABCD and another strip EFGH, they become ABCDDEEFEFGH which creates the degenerate triangles CDD, DDE, DEE, EEF, EFE, FEF.  Using the loop below, I get tiny filaments where the degenerate triangles are positioned and they flicker as the scene is animated:

gl.glCullFace( GL.GL_FRONT );            
gl.glBegin( GL.GL_TRIANGLE_STRIP );
     for ( int i = 0; i < iCount; i++ ){
           vInd = indices.get( i );
           nx = normalCoords.get( vInd + 0 );
           ny = normalCoords.get( vInd + 1 );
           nz = normalCoords.get( vInd + 2 );
           vx = vertexCoords.get( vInd + 0 );
           vy = vertexCoords.get( vInd + 1 );
           vz = vertexCoords.get( vInd + 2 );
           gl.glNormal3d( nx, ny, nz );
           gl.glVertex3d( vx, vy, vz );
     }
gl.glEnd();

When I try to render exactly the same buffer with glDrawElements (which I'd rather use), I get large triangles drawn where there should be only degenerate triangles:

gl.glEnableClientState( GL.GL_VERTEX_ARRAY );
gl.glVertexPointer( 3, GL.GL_FLOAT, 0, vertexCoords );
gl.glEnableClientState( GL.GL_NORMAL_ARRAY );
gl.glNormalPointer( GL.GL_FLOAT, 0, normalCoords );
gl.glDrawElements( GL.GL_TRIANGLE_STRIP, iCount, GL.GL_UNSIGNED_INT, indices );

Why are the two methods producing different results; shouldn't they be equivalent?

How should I set up my buffers to stitch together multiple triangle strips so that it can be used with glDrawElements?  And out of curiosity, why are the filaments being produced in the first code example (shouldn't degenerates just get culled straight away)?

Thanks for any light at all you can shed.