Hi Paul, On Fri, Nov 13, 2009 at 3:20 PM, Paul Martz <[email protected]> wrote: > My apology for not digging into this a couple days ago when I encountered it > (too much other stuff going on). But yes, this is an eyebrow-raiser. So I > checked under the debugger this morning and captured the call stack below. > It appears the culprit is the static s_extensions at like 59 in > BlendColor.cpp... > >> osg61-osgd.dll!osg::DisplaySettings::readEnvironmentalVariables() >> Line 214 C++ > osg61-osgd.dll!osg::DisplaySettings::DisplaySettings() Line 44 C++ > osg61-osgd.dll!osg::DisplaySettings::instance() Line 28 + 0x42 bytes > C++ > > osg61-osgd.dll!osg::buffered_value<osg::ref_ptr<osg::BlendColor::Extensions> >>::buffered_value<osg::ref_ptr<osg::BlendColor::Extensions> >() Line 32 + > 0x50 bytes C++ > osg61-osgd.dll!`dynamic initializer for 's_extensions''() Line 59 + > 0xd bytes C++ > msvcr90d.dll!6601c02c()
Thanks for the investigation work. What we need to do then is move the static declarations inside getExtension() calls, in the BlendColor case BlendColor::getExtensions(..) method is probably the place to put it, and then remove the setExtension() method, which could probably be eradicated as it's not likely to be used, and by changing the return type of BlendColor::getExtensions(..) to a ref_ptr<>& we'd still offer the ability to override the extensions object. Before diving into this we'd need to do a review of how places these global buffered_* statics are used in the context. As a general note we need to move away from have these global statics and use the technique of placing the static in methods/functions to protect there construction order. I'm currently designing support glShaderBinary, and once I've got this implemented I'll have a look at this statics issue. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
