Hi Dirk, Thanks for the reply ! I think you are correct, the field container pointer is leaked upon creation of new materials.
I did another test with a simple material below ######################################################################## OSG::SimpleMaterialRefPtr defaultMaterial() { // shaded simple material OSG::SimpleMaterialRefPtr simplemat(OSG::SimpleMaterial::create()); beginEditCP(simplemat); { simplemat->setAmbient (OSG::Color3f(0.0,0.0,0.0)); simplemat->setDiffuse (OSG::Color3f(0.8,0.8,0.8)); simplemat->setEmission (OSG::Color3f(0.8,0.8,0.8)); simplemat->setSpecular (OSG::Color3f(0.4,0.4,0.4)); simplemat->setShininess (80); simplemat->setTransparency (0.0); simplemat->setLit(true); } endEditCP(simplemat); return simplemat; } for ( int i = 0 ; i<10000 ; ++i ) { OSG::SimpleMaterialRefPtr simplemat = defaultMaterial(); } ######################################################################## and I get a leak of 544 KB. Here's the stack I retrieved from Instruments ######################################################################## 15 MyApp 544.00 KB (anonymous namespace)::buildMaterial() 14 MyApp 544.00 KB (anonymous namespace)::defaultMaterial() 13 libOSGSystem.dylib 544.00 KB osg::SimpleMaterial::changed(unsigned long long, unsigned int) /Users/sbz/src/OpenSG/Source/System/Material/OSGSimpleMaterial.cpp:160 12 libOSGSystem.dylib 544.00 KB osg::ChunkMaterial::changed(unsigned long long, unsigned int) /Users/sbz/src/OpenSG/Source/System/Material/OSGChunkMaterial.cpp:130 11 libOSGSystem.dylib 544.00 KB osg::Material::changed(unsigned long long, unsigned int) /Users/sbz/src/OpenSG/Source/System/Material/OSGMaterial.cpp:184 10 libOSGSystem.dylib 544.00 KB osg::SimpleMaterial::rebuildState() /Users/sbz/src/OpenSG/Source/System/Material/OSGSimpleMaterial.cpp:223 9 libOSGSystem.dylib 544.00 KB osg::StateBase::create() /Users/sbz/src/OpenSG/Source/System/State/OSGStateBase.inl:79 8 libOSGSystem.dylib 544.00 KB osg::StateBase::shallowCopy() const /Users/sbz/src/OpenSG/Source/System/State/OSGStateBase.cpp:123 7 libOSGSystem.dylib 544.00 KB void osg::FieldContainer::newPtr<osg::FCPtr<osg::FieldContainerPtr, osg::State> >(osg::FCPtr<osg::FieldContainerPtr, osg::State>&, osg::FCPtr<osg::FieldContainerPtr, osg::State>::StoredObjectType const*) /Users/sbz/src/OpenSG/Source/System/FieldContainer/Impl/OSGFieldContainerImpl.inl:164 6 libOSGSystem.dylib 544.00 KB osg::FieldContainerFactory::registerFieldContainer(osg::FieldContainerPtr const&) /Users/sbz/src/OpenSG/Source/System/FieldContainer/Impl/OSGFieldContainerFactoryImpl.inl:115 5 libOSGSystem.dylib 544.00 KB std::vector<osg::FieldContainerPtr, std::allocator<osg::FieldContainerPtr> >::push_back(osg::FieldContainerPtr const&) /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/bits/stl_vector.h:610 4 libOSGSystem.dylib 544.00 KB std::vector<osg::FieldContainerPtr, std::allocator<osg::FieldContainerPtr> >::_M_insert_aux(__gnu_cxx::__normal_iterator<osg::FieldContainerPtr*, std::vector<osg::FieldContainerPtr, std::allocator<osg::FieldContainerPtr> > >, osg::FieldContainerPtr const&) /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/bits/vector.tcc:275 3 libOSGSystem.dylib 544.00 KB std::_Vector_base<osg::FieldContainerPtr, std::allocator<osg::FieldContainerPtr> >::_M_allocate(unsigned long) /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/bits/stl_vector.h:117 2 libOSGSystem.dylib 544.00 KB __gnu_cxx::new_allocator<osg::FieldContainerPtr>::allocate(unsigned long, void const*) /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/ext/new_allocator.h:88 1 libstdc++.6.dylib 544.00 KB operator new(unsigned long) 0 libSystem.B.dylib 544.00 KB malloc ######################################################################## Are ref pointers created for every parameters of the material ? Also, is it possible to reset or flush the FieldContainer vector ? We are frequently unloading - reloading 3d models and at the same time building switch materials of a dozen custom materials. Memory builds up very fast, and leaks a little bit at every operation. Also, I still have a memory leak with MaterialPtr, but NodePtr and other ref counted pointers seem to be freed properly, or at the very least, memory leaks do not show in instruments reports. Anyway, thanks for your time, Simon
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1
_______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users