>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.
--
=====================================
Marc Bernatchez
Candidat au Ph.D.
Ecole Polytechnique de Montreal
Montreal, QC, CANADA
=====================================
Virtual Reality web site, VResources:
http://vresources.org
=====================================
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
