[osg-users] Deleting still referenced object
Chris Hanson
xenon at alphapixel.com
Tue Jan 22 13:12:51 PST 2019
Would it make sense to custom hack a BUNCH of asserts into the suspect code
to validate all possible assumptions at runtime and maybe pinpoint
erroneous conditions prior to hitting the actual crash?
On Tue, Jan 22, 2019 at 9:42 PM Robert Osfield <robert.osfield at gmail.com>
wrote:
> 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
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
--
Chris 'Xenon' Hanson, omo sanza lettere. Xenon at AlphaPixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
623-PIXL [7495]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20190122/b02f5ebd/attachment.html>
More information about the osg-users
mailing list