[osg-users] Deleting still referenced object

Richard Harrison rjh at zaretto.com
Tue Jan 22 09:57:53 PST 2019


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



More information about the osg-users mailing list