Hi Carsten, We're using a recent CVS build (Checked-out in may I'd say), but I tested again with an up to date cvs check out, and I obtain the same results.
By talking with you, I'm pretty sure what leaks is only the FC vector. Our problem is that for every model and every geometry node of that model, we create switch materials which replace existing material with sets of custom materials. Since every material leaks a little bit, it just adds up. I just tested with a model containing several sub-nodes, and it does leak about 64 kb of Material FC pointers. Once again, not much, but noticeable. Anyway, I understand the inherant limitations of the FieldContainer design. With that in mind, I can probably build something around it. Thank you, Simon On Tue, Sep 13, 2011 at 7:25 PM, Carsten Neumann <carsten_neum...@gmx.net>wrote: > Hello Simon, > > On 09/13/2011 02:10 PM, Simon Bouvier-Zappa wrote: > > I did another test with a simple material below > > > [SNIP - code] > > 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 > > ######################################################################## > > that looks like (assuming I'm reading the output correctly) it is the > FieldContainerFactory's store of all created FC. > Have you looked at the information on > http://www.opensg.org/wiki/Tutorial/OpenSG1/Memleak? > > > Are ref pointers created for every parameters of the material ? > > Also, is it possible to reset or flush the FieldContainer vector ? > > not trivially so, because it is used to map from a container's id to a > pointer to the container. OpenSG 2 uses a hash map for this data structure. > > > 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. > > hmm, while the FC Factory's vector can get large it should still be > fairly small compared to geometric data and textures... > > > 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. > > Are you using a CVS checkout of OpenSG 1.x (from when?) or the 1.9 > release code? If the latter I'd highly recommend using a CVS checkout > instead, it's seen quite a few bug fixes since 1.8 was released. > > Cheers, > Carsten > > > ------------------------------------------------------------------------------ > 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 >
------------------------------------------------------------------------------ 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
