Hi Ola, I don't think your suggested change will help as you are taking a reference to a potentially deleted object, the Terrain::_mutex that is locked doesn't effected the children just the management of the Terrain::_terrainTileMap and _updateTerrainTileSet.
My current thought is that we'll need to introduce a form of set that manages a list of observer_ptr<> much in the same way that the ObserverNodePath is managed, so we'll need an equivalent ObserverNodeSet class. Robert. On 27 August 2012 12:46, Ola Nilsson <[email protected]> wrote: > Hi Robert et al., > > I finally got the time to investigate the code (osgTerrain/Terrain.cpp). > > As I see it, it is not necessary to introduce a new data structure to hold > the list of update tiles. The issue was that a TerrainTile could be partly > destructed but not unregisterTile:ed, when an Terrain::update call was made. > Then, a TerrainTile could get its refcount bumped while being destructed and > be deleted with a dangling ref_ptr to deleted memory. > > My solution is inspired by the code in ObserverSet::addRefLock and only > modifies Terrain::traverse. I bump the raw Terrain-pointers in the update > list to ref_ptr and check their status before doing any work on them. > TerrainTiles with a refcount of 1 should be discarded (but not deleted). > > I have attached the complete file. Should this conversation be continued at > osg-submissions also/instead? > > Cheers, > > Ola > > >> Hi Ola et. al, >> >> I've looked at the problem Terrain containers and they present an >> interesting issue - the std::set<TerrainTile*> that is used can't >> easily be converted into an std::set< osg::observer_ptr<TerrainTile> > >> as the observer_ptr<> can have it's value changed to NULL by another >> thread when destructing the observed TerrainTile and std::set<> >> require their values to be const. >> >> What will be required is a custom container of osg::oberserver_ptr<> >> along the lines of osg::OberservedNodePath but written to manage it's >> contents in a similar way to a std::set. >> >> Robert. >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > Using Opera's revolutionary email client: http://www.opera.com/mail/ > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
