Hi JS, If the buffer_value is being resize multi-threaded then this in an indication that the the buffer isn't a large enough value before threading started.
osgViewer should set the size of number of contexts that tracked via buffer_value, and the scene graph itself has support for resizing the value via the Node::resizeGLObjectsBuffers(uint) method, this method also exists in StateSet, StateAttribute and Drawable so in theory it should be possible to make sure all the buffers have a big enough size that they don't need resetting during the cull traversal or draw traversal when multi-threading is happening. I haven't yet had a look at your example, ss I'm currently focused on some other rather technical work, so can't pinpoint at what point things aren't kept properly in sync. Once I'm clear of this I should be able to get back to it. In the mean time have using DisplaySettings::setMaxNumberOfGraphicsContexts(uint) to make sure enough contexts are set up are the begging. On try calling viewer.getSceneData()->resizeGLObjectsBuffers(uint) prior to restarting the viewer threads. Robert. On Tue, Aug 31, 2010 at 8:35 PM, Jean-Sébastien Guay <[email protected]> wrote: > Hello Robert, all, > > I'm seeing a crash in our simulator after many scenario loads. The stack > trace differs, but it's always similar to this: > > a) Thread A is calling osg::Texture2D::getModifiedCount() for a new > contextID, causing the _modifiedCount variable (which is an > osg::buffered_value) to be resized. > b) At the same time, Thread B is calling > osg::Texture::getTextureParameterDirty() for a new contextID (different from > the one in a), causing the _texParametersDirtyList variable (also an > osg::buffered_value) to be resized. > > The osg::Texture and osg::Texture2D in threads A and B are the same object. > But the graphics context for which these operations happen is different. > Both threads are running the osgUtil::GLObjectsVisitor (starting from > osgViewer::Renderer::compile()) when this happens. > > The stack trace can differ in the sense that instead of getModifiedCount(), > thread A could be calling applyTexImage2D_load() or some other method on > that same Texture. But getTextureParameterDirty() is always involved in the > other thread from what I've seen. The crash happens in operator delete in > thread B, while trying to resize the _texParametersDirtyList variable. The > crash can happen at the second scenario load, or at the fifth, or at the > 15th. And only if there are two or more GraphicsContexts running at the same > time, so using a single window doesn't reproduce the problem. > > I don't see why doing different things in different threads causes a problem > here, but apparently it does. And in general, running the GLObjectsVisitor > from two different threads, one per context, even if it's on the same scene, > should not cause problems, right? > > A workaround I have found is to do the following before the viewer starts > rendering, but after the scene data has been loaded and the viewer has been > realized (so all GraphicsContexts are created): > > a) stop the viewer's threads > b) for each graphics context > b.1) make the context current > b.2) run the GLObjectsVisitor on the scene > b.3) release the context > c) start the viewer's threads > > This basically forces the GLObjectsVisitor to be run for each context > sequentially instead of in parallel, so any resizes that need to happen will > happen single-threaded. After this, the viewer will re-run the > GLObjectsVisitor, but all resizes will already have been done, so there is > no crash. But I shouldn't have to do this. I feel "dirty" even having this > kind of workaround in the code :-) > > The code example I've included demonstrates this. You'll notice we use > osg::GraphicsContext::incrementContextIDUsageCount() to ensure OSG doesn't > reuse old graphics contexts. This is actually required to reproduce this > crash. Also you'll notice the example creates 8 windows, but the problem is > also present when you have 2 screens and use setUpViewAcrossAllScreens() on > a single view, since then 2 contexts are created. This is what happens in > our app. I've just made it create 8 windows so the crash happens quicker. > > In my case, I just run the example and press "esc" each time the viewer > windows appear, and after a few times (generally less than 5 x 8 windows) I > get a crash with the symptoms I gave above. If you uncomment the > ENABLE_WORKAROUND define, and do the same thing, it shouldn't crash (I've > gone to over 30 x 8 windows a few times with no crash). > > Note that I have no idea how OS/compiler dependent this is, perhaps it only > happens on Windows when OSG is compiled with Visual Studio, or something > like that. That's actually something I hope others can help me find out. > > Has anyone encountered something similar to this? > > Thanks in advance, > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay [email protected] > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
