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/
Terrain.cpp
Description: Binary data
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
