Crash with DebugGL

OpenGL Development JOGL Development
#1

Hi,

I experienced the 1.0 release of JSR 231 and when I compiled and executed TestTexture.java I got the following runtime error:


Loading texture...
Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: glGetError() returned the following error codes after a call to glTexParameteri(): GL_INVALID_ENUM 
	at javax.media.opengl.DebugGL.checkGLGetError(DebugGL.java:11724)
	at javax.media.opengl.DebugGL.glTexParameteri(DebugGL.java:8494)
	at com.sun.opengl.util.texture.Texture.updateImage(Texture.java:342)
	at com.sun.opengl.util.texture.Texture.updateImage(Texture.java:244)
	at com.sun.opengl.util.texture.Texture.<init>(Texture.java:88)
	at com.sun.opengl.util.texture.TextureIO.newTexture(TextureIO.java:440)
	at com.sun.opengl.util.texture.TextureIO.newTexture(TextureIO.java:461)
	at demos.texture.TestTexture.display(TestTexture.java:188)
	at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
	at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:281)
	at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
	at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:258)
	at javax.media.opengl.GLCanvas.display(GLCanvas.java:130)
	at javax.media.opengl.GLCanvas.paint(GLCanvas.java:142)
	at sun.awt.RepaintArea.paintComponent(Unknown Source)
	at sun.awt.RepaintArea.paint(Unknown Source)
	at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6957a799, pid=2612, tid=336
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode, sharing)
# Problematic frame:
# C  [ssicdnt.dll+0x7a799]
#
# An error report file with more information is saved as hs_err_pid2612.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

The workaround I found out to this problem is to comment out the line that set up the DebugGL. I think it’s a JOGL bug.

My video card is a 16 megs SuperSavage that supports OGL 1.1 only. It’s an old and low end card that shipped with my laptop. I run with Java 5_08 with WinXP.
Are there minimum OGL requirements to use JOGL?

Any help or idea…?

Thanks

EDIT: And I forgot to mention that I frequently get a VM crash like shown above when I terminate the JOGL programs I run.

#2

Have you specified -Dsun.java2d.noddraw=true on the command line, which is required for all JOGL programs on Windows?

I’m sorry but your video card’s drivers appear to be the problem. I would strongly recommend you upgrade even to a really low-end card. A cheap NVidia card ($20) should completely blow away your current card in terms of reliability, performance and features.

#3

[quote]Have you specified -Dsun.java2d.noddraw=true on the command line, which is required for all JOGL programs on Windows?
[/quote]
Yes I’ve set it in the VM args.

I’d love to upgrade my crappy video card but it’s impossible according to computer vendor unless I change my laptop. If you can prove this vendor to be wrong than I would be more than happy to upgrade.

Other than that, any idea why glGetError returned GL_INVALID_ENUM?

I also have a question: In all the old code samples I looked at around the web the GLCanvas was created from the factory (don’t remember the factory name). Now why we can simply create a GLCanvas from its constructor? What’s the purpose of the factory now?

Thanks for your help!

#4

Yes, that is a problem. A few years ago I bought a new laptop specifically looking for an NVidia graphics chipset in it, and if I were buying a new laptop today I’d use the same criterion.

Looking into this further, it’s because we’re using the GL_CLAMP_TO_EDGE enum value instead of GL_CLAMP. They have slightly different semantics and GL_CLAMP_TO_EDGE was only introduced in OpenGL 1.2. I’ve filed Issue 247 to track this.

This was one of the API changes made for the convenience of the developer later in the JSR-231 standardization process. The factory is still used to instantiate lower-level objects like GLDrawables, which can be used to make your own custom OpenGL widgets that do not subclass GLCanvas.

#5

FYI, sorry for the delay but this bug has finally been fixed. If you could either try a nightly build dated 11/15 or later (note, the nightly builds are going to be down for a few days due to the machines being moved) or try building the source tree yourself I’d appreciate it if you could verify this fix.

#6

I’ll try the new build next week and I’ll keep you informed.

Thanks