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&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the 
BlackBerry&reg; mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry&reg; 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

Reply via email to