Hi everybody,

On further investigation I think this problem could have something to do
with extension querying (with glGetString and/or wgl function calls)
during the initial display list compilation.

Looking at the GLIntercept display list dump for my simple example
(attached), it appears that isGLExtensionSupported is being invoked
between glNewList and glEndList, resulting in all the glGetString/wgl
calls.  I'm sure this is a highly unusual call sequence for an OpenGL
driver, so I wouldn't be shocked if it's triggering a bug.  To test
this, I added an explicit call isGLExtensionSupported(0, "") prior to
SceneView::init to force the extension queries early and the problem
went away.  I'm curious to know if this works for the others who are
having the same problem.

It looks like isGLExtensionSupported is called from various parts of the
code, so perhaps the variability of the problem can be explained by the
function being invoked by some node in the initial scenegraph prior to
the first drawable compilation?

-Mike


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport
Sent: Tuesday, October 03, 2006 2:28 AM
To: osg users
Subject: Re: [osg-users] Re: Problems loading 3DS files since OSG 1.1

Hi,

from previous threads:

it is possible to trigger the bug/feature/weirdness using simply:
osgglutkeyboardmouse cow.osg

so the problem is not 3DS specific. It would also be good, as Robert
suggested, to test with the newer osgsimpleviewerGLUT versus
osgsimpleviewerProducer.

The problem seems to be either timing/variable init related:

* Release vs Debug
- Mike Wittman: My tests have all been done on a Debug build, and I
didn't observe any crashes.  I just tried running a Release build and I
got the same symptoms.

* GL debuggers
- Mike Wittman: When running under GLIntercept the problem goes away.
- Harri Mahonen: As Gian mentioned on other post, osgglutkeyboardmouse
is a fine example to test with. Funny thing was, I downloaded and
installed gDEBugger and ran the application through it and it worked
fine. Run the application from the command line though and no model.

or something to do with display list/texture gen on NVidia:

- Ryan Kawicki: Actually, some of the machines that we ran on would
produce the black screen while others would crash when trying to call
glGenTextures.  We tracked to problem down the Init function and display
lists.  If any drawable was using a display list, the problem would
happen.
- Mike Wittman: It also goes away if the initial scenegraph has no
Drawables to compile.  Even with the initial scene graph pared the to
the bare minimum data -- one Geode containing one Drawable containing
one GL_POINTS primitive, containing one point -- the problem persists.

It could also help to create the simplest osg file to recreate this with
as pointed out by Mike above.

regards
jp

Marc Bernatchez wrote:
>>Hi Marc, Found the sound the nature of this bug I suspect its a memory
> error that only trips you over in certain
>>circumstances, change the cirtcumstances slightly and the bug
> "magically" disappears - for instance debug vs release.
>> Threading issue tend to be like this in nature too, but in this case
> its been reproduce in GLUT examples which are single
>> threaded so this is very unlikely.
> 
> My initial thought was exactly that, like you are saying above. But as
I
> investigate this, it becomes less and less a possibility. If it was a
> memory overrun / corruption case, we would probably have had a
> consistent crash situation. The infamous "it only crashes in release
but
> not in debug" problem is often a memory overrun / corruption problem,
> where a variable is not properly initialized (many of the time, a
lousy
> pointer in the end). Moreover, if it was that, I would expect the
crash
> to happen earlier from inside OSG. It would not have the time to go
down
> all the way inside the nvidia driver. Here, in this case, we are
> probably feeding a wrong data stream format to the driver. Either it
is
> just wrong from an OGL specs compliance perspective, or it is just
> different enough so that it wakes up a bug in the windows-side nvidia
> driver and not the Linux one.
> 
>>Perhaps the new osgsimpleviewerGLUT and osgsimpleviewerProducer
> examples might come in useful here. There are
>> basically the same OSG/OpenGL wise, but have different windowing
API's
> setting up the graphics context. Recently for a
>> client app they hit a problem under Windows using a simple GLUT
> example, I moved this example to using Producer and
>> its been fine ever since, the problem wasn't related the display
lists
> but textuering, I couldn't explain this bug, but
>> Producer's setup fixed.
> 
> I could try that on my side. You are referring to "osgGLUTsimple"
here?
> Do I have anything specific to setpup or would this sample trigger the
> bug without any modifications?
> 
> Since we already saw mention of texture crashes in the past that
looked
> related, I would tend to say it was still hitting the same bug. Were
the
> textures JPGs? I don't know if it is relevant.
> 
>>If this sample trick works with osgsimpleviewerGLUT not working and
> osgsimpleviewerProducer working then we'll be
>> much closer to a bare minumum app that does the same in both cases
> save for the windowing. All the OpenGL tokens
>> should be the same, as they should have been with my clients GLUT vs
> Producer example app.
> 
> I agree. Anything that allows us to narrow it down to the few lines of
> code inside OSG that enable / disable the bug would be great.
> 
>>If the error is on the OSG side then its likely to be an uninitialized
> variable somewhere. The nature of this problem doesn't
>> point to this as the most likely candidate, it has many of the
> hallmarks of a OpenGL driver bug. Robert.
> 
> You could be surprised ;-) One thing is certain thought, it sure
sounds
> like a nasty one.
> 
> Thank you for your support Robert.
> 

-- 

This message is subject to the CSIR's copyright, terms and conditions
and
e-mail legal notice. Views expressed herein do not necessarily represent
the
views of the CSIR.
 
CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html 
 
CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html 
 
For electronic copies of the CSIR Copyright, Terms and Conditions and
the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line
to
[EMAIL PROTECTED]


This message has been scanned for viruses and dangerous content by
MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for
their support.

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
glNewList(1,GL_COMPILE)
glGetString(GL_RENDERER)
glGetString(GL_EXTENSIONS)
wglGetProcAddress("wglGetExtensionsStringARB")
wglGetProcAddress("wglGetExtensionsStringEXT")
wglGetCurrentDC()
wglGetExtensionsStringARB(0xd301048c)
wglGetProcAddress("glFogCoordfv")
wglGetProcAddress("glSecondaryColor3ubv")
wglGetProcAddress("glSecondaryColor3fv")
wglGetProcAddress("glMultiTexCoord1f")
wglGetProcAddress("glMultiTexCoord2fv")
wglGetProcAddress("glMultiTexCoord3fv")
wglGetProcAddress("glMultiTexCoord4fv")
wglGetProcAddress("glVertexAttrib1s")
wglGetProcAddress("glVertexAttrib1f")
wglGetProcAddress("glVertexAttrib2fv")
wglGetProcAddress("glVertexAttrib3fv")
wglGetProcAddress("glVertexAttrib4fv")
wglGetProcAddress("glVertexAttrib4ubv")
wglGetProcAddress("glVertexAttrib4Nubv")
wglGetProcAddress("glGenBuffers")
wglGetProcAddress("glBindBuffer")
wglGetProcAddress("glBufferData")
wglGetProcAddress("glBufferSubData")
wglGetProcAddress("glDeleteBuffers")
wglGetProcAddress("glIsBuffer")
wglGetProcAddress("glGetBufferSubData")
wglGetProcAddress("glMapBuffer")
wglGetProcAddress("glUnmapBuffer")
wglGetProcAddress("glGetBufferParameteriv")
wglGetProcAddress("glGetBufferPointerv")
wglGetProcAddress("glGenOcclusionQueries")
wglGetProcAddress("glGenOcclusionQueriesNV")
wglGetProcAddress("glDeleteOcclusionQueries")
wglGetProcAddress("glDeleteOcclusionQueriesN...")
wglGetProcAddress("glIsOcclusionQuery")
wglGetProcAddress("_glIsOcclusionQueryNV")
wglGetProcAddress("glBeginOcclusionQuery")
wglGetProcAddress("glBeginOcclusionQueryNV")
wglGetProcAddress("glEndOcclusionQuery")
wglGetProcAddress("glEndOcclusionQueryNV")
wglGetProcAddress("glGetOcclusionQueryiv")
wglGetProcAddress("glGetOcclusionQueryivNV")
wglGetProcAddress("glGetOcclusionQueryuiv")
wglGetProcAddress("glGetOcclusionQueryuivNV")
wglGetProcAddress("glGenQueries")
wglGetProcAddress("glDeleteQueries")
wglGetProcAddress("glIsQuery")
wglGetProcAddress("glBeginQuery")
wglGetProcAddress("glEndQuery")
wglGetProcAddress("glGetQueryiv")
wglGetProcAddress("glGetQueryObjectiv")
wglGetProcAddress("glGetQueryObjectuiv")
glEnableClientState(GL_VERTEX_ARRAY)
glVertexPointer(3,GL_FLOAT,0,0x78a4db8)
glDisableClientState(GL_NORMAL_ARRAY)
glDisableClientState(GL_COLOR_ARRAY)
glDisableClientState(GL_SECONDARY_COLOR_ARRAY)
glDisableClientState(GL_FOG_COORDINATE_ARRAY)
wglGetProcAddress("glDisableVertexAttribArra...")
glColor3fv([0.000000,0.000000,0.000000])
glDrawArrays(GL_POINTS,0,1)
glEndList()
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to