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/
