[osg-users] Deleting still referenced object

Robert Osfield robert.osfield at gmail.com
Tue Jan 22 12:42:01 PST 2019


Hi Richard,

Sorry to hear your are battling this issue.  I've read through, and
had a quick look at simgear master but could find the
loadUsingReaderWriter() implementation in ModelRegistry.cxx that you
mention.  Are you working on a branch or not checked something in yet?

As a general comment, if you could use the OpenSceneGraph-3.6 branch
rather than master it should give you a more stable and tested OSG
base to work from.  I'd also recommend checking the whole model
loading/processing path to make sure all the methods are taking and
passing back ref_ptr<> rather than C pointer.  In my quick check I
spotted a osg::Node* OptimizeModelPolicy::optimize() method that be
something could be the type of thing to convert across to ref_ptr<>.

Robert.

On Tue, 22 Jan 2019 at 17:58, Richard Harrison <rjh at zaretto.com> wrote:
>
> I've just got another of these problems.
>
> This is after changing all of the osgDB::read into osgDB::readRef
> (simgear commit cb024dd82d4c384df0b599640a98e762fbf66688) and 5days of
> flight time testing (not all the same run, FG was restarted many
> times) I've hit what looks like a the same problem as I originally
> reported; i.e. the expiry appears to be something that has just been
> loaded and expired at the same time. I'm keeping my debug session open
> to allow further investigation in case questions.
>
> I'm surprised that the fixes didn't work as they looked to me as
> though they should fix the problem I'm immediately suspecting that
> maybe there are other things that we're doing that are interfering
> with the thread safety mechanisms.
>
> Having dug into what's happening; the DatabasePager is currently
> loading Models/Airport/cargoim.xml; which is defined in
> project3000/Objects/w010n50/w002n52/2925458.stg; and the ObjectCache
> is expiring Models/Aircraft/Cessna172_red.ac; Looking at the pertinent
> part of the .stg it is a fair conclusion that the DatabasePager has
> just loaded two Cessna172_red.ac models
>
> OBJECT_SHARED Models/Aircraft/Cessna172_red.ac -1.47630 52.37373 82.02
> 223.53
> OBJECT_SHARED Models/Aircraft/Cessna172_red.ac -1.47560 52.37443 81.34 345.5
> OBJECT_SHARED Models/lib/trailer-fedex.ac -1.48893 52.36957 84.13 314.01
> OBJECT_SHARED Models/Airport/cargoim.xml -1.47436 52.36886 79.91 188.47
>
> The actual .ac model load is happening in SGReaderWriteXML.cxx line 341
>
>      modelResult = osgDB::readRefNodeFile(modelpath.local8BitStr(),
> options.get());
>
> which will end up in ModelRegistry.cxx line 866
>
>      loadUsingReaderWriter(const std::string& fileName,
>                            const osgDB::Options* opt)
>      {
>          using namespace osgDB;
>          ReaderWriter* rw =
>              Registry::instance()
>              ->getReaderWriterForExtension
>                (osgDB::getFileExtension(fileName));
>          if (!rw)
>              return ReaderWriter::ReadResult(); // FILE_NOT_HANDLED
>          return rw->readNode(fileName, opt);
>      }
>
> I think it is correct in this instance to use the (ac3d) via the
> registry and readNode.
>
> The only other thing that looks a bit odd is the way we are requesting
> the same .stg file multiple times; maybe that is tripping something up
> in our code; but I don't think that's the cause of the deleting whilst
> still in use.
>
>    [0..162] i:/flightgear/project3000/Objects/w010n50/w002n52/2925458.stg
>    [163..178] i:/flightgear/project3000/Objects/w010n50/w002n52/2925458.stg
>    [179..] i:/flightgear/terrasync/Terrain/w010n50/w002n52/2925458.stg
>
>
> -------------------
> On 17/01/2019 14:39, Voerman, L. wrote the following questions:
>
>  > - did the problematic node come out of the cache, or did it come
> fresh from disk?
>
> It's hard to tell because as far as I can tell the problematic load has
> finished and the pager has moved onto the next item.
>
>  > - Is the parent group (and it's _children vector) still sane?
>
> Looking at the node that is being expired it all looks good; the
> reference count is 3; so there remains the mystery of how this can
> happen.
>
>          oitr (
>                  ("Models/Aircraft/Cessna172_red.ac",
>                  {_ptr=0x0 <NULL> }),
>                  ({_ptr=0x2441e8bc800 {_children={ size=0x5 } } },
>                  5002.8604968999998))
>          first   "Models/Aircraft/Cessna172_red.ac"
>          second  {_ptr=0x0 <NULL> }
>          second  ({_ptr=0x2441e8bc800 {_children={ size=0x5 } } },
>                   5002.8604968999998)
>              first   {_ptr=0x2441e8bc800 {_children={ size=0x5 } } } o
>                       sg::ref_ptr<osg::Object>
>              _ptr    0x2441e8bc800 {_children={ size=0x5 } }
>                      osg::Object * {osg160-osg.dll!osg::Group}
>          [osg::Group]
>              {_children={ size=0x5 } } osg160-osg.dll!osg::Group
>                  osg::Node   {...}
>                      osg::Object
>                      {
> _name="I:\flightgear\terrasync\Models\Aircraft\Cessna172_red.ac"
>            _dataVariance=STATIC (0x1) ...
>                      }
>              _initialBound
>              {_center={_v=0x2441e8bc848 {0.0, 0.0, 0.0} } _radius=-1.0 }
>              _boundingSphere {
>                  _center={_v=0x2441e8bc860 {0.0, 0.0, 0.0} }
>                  _radius=-1.0 }
>              _boundingSphereComputed false   bool
>              _parents    { size=0x2 }
>              _numChildrenRequiringUpdateTraversal
>              _cullingActive  true
>              _nodeMask   0xffffdfff
>              _children   { size=0x5 }
>              osg::Referenced {_observerSet={_ptr=0x0 }
>              _refCount={_value=0x3 } }
>              _dataVariance   STATIC (0x1)
>              _userDataContainer  0x0
>          second  5002.8604968999998
>
>  > - If the parent node is still sane, can you match it to the file on
>  > disk and possibly tell what sort of node the problem appears in?  -
>  > What is the file format of the file on disk? Do you have (use)
>  > multiple pager threads? Could the file loader have a multithreading
>  > problem?
>
> It's a .ac format node; we're using a single DatabasePager thread (as
> there are other loading problems within FG that almost prevent it from
> running at all)
>
> --------------------------
> Stack dumps are as follows:
>
> Main thread;
>      fgfs.exe!NotifyLogger::notify
>      osg160-osg.dll!osg::NotifyStreamBuffer::sync L:92
>      msvcp140.dll!00007ffabb8a27f2
>      osg160-osg.dll!std::endl
>      osg160-osg.dll!osg::Referenced::~Referenced() L:205
>      osgdb_ac.dll!osg::Group::`scalar deleting destructor'
>      osg160-osg.dll!osg::Referenced::signalObserversAndDelete() L:294
>      osg160-osg.dll!osg::Referenced::unref() L:203
>      osg160-osgDB.dll!std::erase L:1431
>      osg160-osgDB.dll!osgDB::ObjectCache::removeExpiredObjectsInCache L:171
>      osg160-osgViewer.dll!osgViewer::Viewer::updateTraversal() L:1161
>      osg160-osgViewer.dll!osgViewer::ViewerBase::frame L:748
>      fgfs.exe!fgOSMainLoop() L:339
>      fgfs.exe!fgMainInit(int argc, char * * argv) L:619
>      fgfs.exe!main(int argc, char * * argv) L:339
>      fgfs.exe!__scrt_common_main_seh() L:253
>
> DatabasePager thread
>
>      ntdll.dll!00007ffaefd51db4
>      KernelBase.dll!00007ffaec855834
>      KernelBase.dll!00007ffaec855bcc
>      kernel32.dll!00007ffaef606413
>      kernel32.dll!00007ffaef642d42
>      osg160-osgDB.dll!osgDB::getRealPath
>      osg160-osgDB.dll!osgDB::findFileInPath
>      osg160-osgDB.dll!osgDB::findFileInPath
>      osg160-osgDB.dll!osgDB::Registry::findDataFileImplementation
>      osg160-osgDB.dll!osgDB::Registry::findDataFile
>      osg160-osgDB.dll!osgDB::findDataFile
>      fgfs.exe!simgear::SGReaderWriterXML::readNode
> fgfs.exe!simgear::ModelRegistryCallback<>::loadUsingReaderWriter
>      fgfs.exe!simgear::ModelRegistryCallback<>::readNode
>      fgfs.exe!simgear::ModelRegistry::readNode
>      osg160-osgDB.dll!osgDB::Registry::readNode
>      osg160-osgDB.dll!osgDB::readRefNodeFile
> fgfs.exe!simgear::ReaderWriterSTG::_ModelBin::DelayLoadReadFileCallback
>                                      ::AddModelLOD::operator
>      fgfs.exe!simgear::QuadTreeBuilder<>::addNode
>      fgfs.exe!simgear::QuadTreeBuilder<>::buildQuadTree
>      fgfs.exe!simgear::ReaderWriterSTG::_ModelBin
> ::DelayLoadReadFileCallback::readNode
>      osg160-osgDB.dll!osgDB::Registry::readNode
>      osg160-osgDB.dll!osgDB::DatabasePager::DatabaseThread::run
> ot21-OpenThreads.dll!OpenThreads::ThreadPrivateActions::StartThread
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


More information about the osg-users mailing list