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 <r...@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@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
