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
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users