Re: [osg-users] Deleting still referenced object

[Robert Osfield]

Hi Richard,

I'll tag another 3.6.4 release candidate today, this will be based on
the OpenSceneGraph-3.6 branch.  Hopefully with your own simgear
changes and 3.6 things will work fine and I can go for the final 3.6.4
release in knowledge that things are working fine.

Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Richard Harrison]

Hi Robert;



As a general comment, if you could use the OpenSceneGraph-3.6 branch
I'm still using 3.7 - I'll switch over to 3.6 soon; although it's a bit 
tedious because I have to rebuild everything and it takes a good few hours.



base to work from.  I'd also recommend checking the whole model
loading/processing path to make sure all the methods are taking and
I did this by setting breakpoints on the non Ref methods in object cache 
and this lead me straight to the problem (my incredlible idoicy) - in 
that I failed to merge in your changes in the version I committed (i.e. 
the fix to simgear I've committed doesn't include the fix to 
DefaultCachePolicy::find). So the version I started testing on Sunday 
(after committing) failed; whereas the versions I was testing all last 
week are fine.


So almost certainly my report is incorrect and it's working fine; which 
is a relief and I apologise for wasting your time.


I will verify the other methods. I don't think optimise is important 
because it's working with an already loaded model which I think has come 
from a ReadResult; but I'll check this.


--Richard



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Chris Hanson]

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 
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  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  }),
> >  ({_ptr=0x2441e8bc800 {_children={ size=0x5 } } },
> >  5002.860496898))
> >  first   "Models/Aircraft/Cessna172_red.ac"
> >  second  {_ptr=0x0  }
> >  second  ({_ptr=0x2441e8bc800 {_children={ size=0x5 } } },
> >   5002.860496898)
> >  first   {_ptr=0x2441e8bc800 {_children={ size=0x5 } 

Re: [osg-users] Deleting still referenced object

[Robert Osfield]

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  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  }),
>  ({_ptr=0x2441e8bc800 {_children={ size=0x5 } } },
>  5002.860496898))
>  first   "Models/Aircraft/Cessna172_red.ac"
>  second  {_ptr=0x0  }
>  second  ({_ptr=0x2441e8bc800 {_children={ size=0x5 } } },
>   5002.860496898)
>  first   {_ptr=0x2441e8bc800 {_children={ size=0x5 } } } o
>   sg::ref_ptr
>  _ptr0x2441e8bc800 {_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) 

Re: [osg-users] Deleting still referenced object

[Richard Harrison]

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  }),
    ({_ptr=0x2441e8bc800 {_children={ size=0x5 } } },
    5002.860496898))
    first   "Models/Aircraft/Cessna172_red.ac"
    second  {_ptr=0x0  }
    second  ({_ptr=0x2441e8bc800 {_children={ size=0x5 } } },
 5002.860496898)
    first   {_ptr=0x2441e8bc800 {_children={ size=0x5 } } } o
 sg::ref_ptr
    _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   0xdfff
    _children   { size=0x5 }
    osg::Referenced {_observerSet={_ptr=0x0 }
    _refCount={_value=0x3 } }
    _dataVariance   STATIC (0x1)
    _userDataContainer  0x0
    second  5002.860496898

> - 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 

Re: [osg-users] Deleting still referenced object

[Richard Harrison]

On 17/01/2019 14:39, Voerman, L. wrote:
I am out of suggestions, but here are a few questions that I can come 
up with:


Thanks; much appreciated.


- did the problematic node come out of the cache, or did it come fresh 
from disk?

  (modelResult._status has this info)


        modelResult    {_status=FILE_LOADED (0x0004) _message="" 
_object={_ptr=0x01dbb1f39920 {_observerSet={_ptr=0x 
} ...} } } osgDB::ReaderWriter::ReadResult



> Are you sure your build is clean? You say you build osg master, but 
from your stack trace


That's a fair point - I'll do a clean build of master; I was using the 
FG fork of 3.4.2 for this test, but it wasn't cleaned - so this result 
could well be something else. Once I've built master I'll redo the test.


I'll defer the rest of your questions until I get a repeat of the 
problem with master


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Voerman, L.]

I am out of suggestions, but here are a few questions that I can come up
with:
- did the problematic node come out of the cache, or did it come fresh from
disk?
  (modelResult._status has this info)
- Is the parent group (and it's _children vector) still sane?
- 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?

Unless the node is a proxy or pagedlod this appears to be a different
problem than the cache release problem. You say the node looks like
deleted,  all I can conclude is that the Node* doesn't point to a valid
node.

Other annoying questions:
Are you sure your build is clean? You say you build osg master, but from
your stack trace
osg130-osg.dll!osg::clone
osg130-osg.dll  hints at osg 3.4.0 or 3.4.1 Release candidate 2


Regards, Laurens.


On Thu, Jan 17, 2019 at 11:25 AM Richard Harrison  wrote:

> Hi Lawrence;
>
> Thanks for the help.
>
> Sorry for the confusion; it doesn't actually fail on that line; it fails
> deep inside CopyOp; this is the stack trace from the previous code;
>
> osg130-osg.dll!osg::CopyOp::operator()(const osg::Node * node) Line
> 56C++
>   osg130-osg.dll!osg::Group::Group(const osg::Group & group, const
> osg::CopyOp & copyop) Line 40C++
>   osg130-osg.dll!osg::Group::clone(const osg::CopyOp & copyop) Line
> 38C++
>   osg130-osg.dll!osg::clone(const osg::Node * t, const
> osg::CopyOp & copyop) Line 250C++
>   osg130-osg.dll!osg::Group::Group(const osg::Group & group, const
> osg::CopyOp & copyop) Line 40C++
>   osg130-osg.dll!osg::Group::clone(const osg::CopyOp & copyop) Line
> 38C++
>   osg130-osg.dll!osg::clone(const osg::Node * t, const
> osg::CopyOp & copyop) Line 250C++
>   fgfs.exe!simgear::copyModel(osg::Node * model) Line 94C++
>   fgfs.exe!sgLoad3DModel_internal(const SGPath & path, const
> osgDB::Options * dbOptions, SGPropertyNode * overlay) Line 342C++
>
> copy model (simgear model.cxx:84) uses the following flags.
>
> Node* copyModel(Node* model)
> {
>  const CopyOp::CopyFlags flags = (CopyOp::DEEP_COPY_ALL
>   & ~CopyOp::DEEP_COPY_TEXTURES
>   & ~CopyOp::DEEP_COPY_IMAGES
>   & ~CopyOp::DEEP_COPY_STATESETS
>   & ~CopyOp::DEEP_COPY_STATEATTRIBUTES
>   & ~CopyOp::DEEP_COPY_ARRAYS
>   & ~CopyOp::DEEP_COPY_PRIMITIVES
>   // This will preserve display
> lists ...
>   & ~CopyOp::DEEP_COPY_DRAWABLES
>   & ~CopyOp::DEEP_COPY_SHAPES);
>  return (CopyOp(flags))(model);
> }
>
> At the top of the stack inside operator() the node in question is all
> garbage - which looks like something that has been deleted.
>
>  osg::Object{_name={...} _dataVariance=???
> _userDataContainer=??? }osg::Object
>  _initialBound{_center={_v=0x8003d900ed55904f {???, ???,
> ???} } _radius=??? } osg::BoundingSphereImpl
>  _computeBoundCallback{_ptr=??? }
> osg::ref_ptr
>  _boundingSphere{_center={_v=0x8003d900ed559067 {???, ???,
> ???} } _radius=??? } osg::BoundingSphereImpl
>  _boundingSphereComputed
>  _parents{ size=??? }std::vector *,std::allocator >
>  _updateCallback{_ptr=??? } osg::ref_ptr
>  _numChildrenRequiringUpdateTraversal
>  _eventCallback{_ptr=??? } osg::ref_ptr
>  _numChildrenRequiringEventTraversal
>  _cullCallback{_ptr=??? } osg::ref_ptr
>  _cullingActive
>  _numChildrenWithCullingDisabled
>  _numChildrenWithOccluderNodes
>  _nodeMask
>  _stateset{_ptr=??? } osg::ref_ptr
>
> On 17/01/2019 10:56, Voerman, L. wrote:
>
> > Hi Richard,
> > I can't see how you can get a segfault on the line you indicate, so I
> > guess the node is somehow corrupted and the segfault is somewhere in
> > the copyOp.
> > I can only guess at what might be going wrong there, but my first
> > guess would be the DEEP_COPY_USERDATA.
> > Laurens.
> >
> > On Thu, Jan 17, 2019 at 8:13 AM Richard Harrison  > > wrote:
> >
> > On 15/01/2019 09:03, Robert Osfield wrote:
> >
> > >> illustrated it well) and I'm currently flying one of my long
> > test routes.
> > > Fingers and toes crossed.
> >
> > ..and alas after 30h I've got a similar looking problem; the
> > pattern is
> > the same i.e. DatabasePager loading something whilst ObjectCache is
> > expiring.
> >
> > This time it's a segfault in the DatabasePager during a copy of a
> > model
> >

Re: [osg-users] Deleting still referenced object

[Richard Harrison]

Hi Lawrence;

Thanks for the help.

Sorry for the confusion; it doesn't actually fail on that line; it fails 
deep inside CopyOp; this is the stack trace from the previous code;


osg130-osg.dll!osg::CopyOp::operator()(const osg::Node * node) Line 
56    C++
 osg130-osg.dll!osg::Group::Group(const osg::Group & group, const 
osg::CopyOp & copyop) Line 40    C++
 osg130-osg.dll!osg::Group::clone(const osg::CopyOp & copyop) Line 
38    C++
 osg130-osg.dll!osg::clone(const osg::Node * t, const 
osg::CopyOp & copyop) Line 250    C++
 osg130-osg.dll!osg::Group::Group(const osg::Group & group, const 
osg::CopyOp & copyop) Line 40    C++
 osg130-osg.dll!osg::Group::clone(const osg::CopyOp & copyop) Line 
38    C++
 osg130-osg.dll!osg::clone(const osg::Node * t, const 
osg::CopyOp & copyop) Line 250    C++

 fgfs.exe!simgear::copyModel(osg::Node * model) Line 94    C++
 fgfs.exe!sgLoad3DModel_internal(const SGPath & path, const 
osgDB::Options * dbOptions, SGPropertyNode * overlay) Line 342    C++


copy model (simgear model.cxx:84) uses the following flags.

Node* copyModel(Node* model)
{
    const CopyOp::CopyFlags flags = (CopyOp::DEEP_COPY_ALL
 & ~CopyOp::DEEP_COPY_TEXTURES
 & ~CopyOp::DEEP_COPY_IMAGES
 & ~CopyOp::DEEP_COPY_STATESETS
 & ~CopyOp::DEEP_COPY_STATEATTRIBUTES
 & ~CopyOp::DEEP_COPY_ARRAYS
 & ~CopyOp::DEEP_COPY_PRIMITIVES
 // This will preserve display 
lists ...

 & ~CopyOp::DEEP_COPY_DRAWABLES
 & ~CopyOp::DEEP_COPY_SHAPES);
    return (CopyOp(flags))(model);
}

At the top of the stack inside operator() the node in question is all 
garbage - which looks like something that has been deleted.


        osg::Object    {_name={...} _dataVariance=??? 
_userDataContainer=??? }    osg::Object
        _initialBound    {_center={_v=0x8003d900ed55904f {???, ???, 
???} } _radius=??? } osg::BoundingSphereImpl
        _computeBoundCallback    {_ptr=??? } 
osg::ref_ptr
        _boundingSphere    {_center={_v=0x8003d900ed559067 {???, ???, 
???} } _radius=??? } osg::BoundingSphereImpl

        _boundingSphereComputed    
        _parents    { size=??? }    std::vector*,std::allocator >

        _updateCallback    {_ptr=??? } osg::ref_ptr
        _numChildrenRequiringUpdateTraversal    
        _eventCallback    {_ptr=??? } osg::ref_ptr
        _numChildrenRequiringEventTraversal    
        _cullCallback    {_ptr=??? } osg::ref_ptr
        _cullingActive    
        _numChildrenWithCullingDisabled    
        _numChildrenWithOccluderNodes    
        _nodeMask    
        _stateset    {_ptr=??? } osg::ref_ptr

On 17/01/2019 10:56, Voerman, L. wrote:


Hi Richard,
I can't see how you can get a segfault on the line you indicate, so I 
guess the node is somehow corrupted and the segfault is somewhere in 
the copyOp.
I can only guess at what might be going wrong there, but my first 
guess would be the DEEP_COPY_USERDATA.

Laurens.

On Thu, Jan 17, 2019 at 8:13 AM Richard Harrison > wrote:


On 15/01/2019 09:03, Robert Osfield wrote:

>> illustrated it well) and I'm currently flying one of my long
test routes.
> Fingers and toes crossed.

..and alas after 30h I've got a similar looking problem; the
pattern is
the same i.e. DatabasePager loading something whilst ObjectCache is
expiring.

This time it's a segfault in the DatabasePager during a copy of a
model
that has just been loaded (simgear, SGReaderWriterXML.cxx:342)

options->setDatabasePath(texturepath.local8BitStr());
 osgDB::ReaderWriter::ReadResult modelResult;
 modelResult =
osgDB::readRefNodeFile(modelpath.local8BitStr(),
options.get());
 if (!modelResult.validNode())
 throw sg_io_exception("Failed to load 3D model:" +
modelResult.message(),
   modelpath);
 >   model = copyModel(modelResult.getNode());

The object currently being expired in the ObjectCache doesn't seem to
bear any relation to the model being loaded; one is a windsock and
the
other a radio tower.

This is after I changed all of the osg::getSomething into
osg::getRefSomething.

I'm now a little confused as I was sure that the fix would work; I've
kept the debug session open in case there is anything that I need to
inspect.


___
osg-users mailing list
osg-users@lists.openscenegraph.org

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing 

Re: [osg-users] Deleting still referenced object

[Voerman, L.]

Hi Richard,
I can't see how you can get a segfault on the line you indicate, so I guess
the node is somehow corrupted and the segfault is somewhere in the copyOp.
I can only guess at what might be going wrong there, but my first guess
would be the DEEP_COPY_USERDATA.
Laurens.

On Thu, Jan 17, 2019 at 8:13 AM Richard Harrison  wrote:

> On 15/01/2019 09:03, Robert Osfield wrote:
>
> >> illustrated it well) and I'm currently flying one of my long test
> routes.
> > Fingers and toes crossed.
>
> ..and alas after 30h I've got a similar looking problem; the pattern is
> the same i.e. DatabasePager loading something whilst ObjectCache is
> expiring.
>
> This time it's a segfault in the DatabasePager during a copy of a model
> that has just been loaded (simgear, SGReaderWriterXML.cxx:342)
>
>  options->setDatabasePath(texturepath.local8BitStr());
>  osgDB::ReaderWriter::ReadResult modelResult;
>  modelResult = osgDB::readRefNodeFile(modelpath.local8BitStr(),
> options.get());
>  if (!modelResult.validNode())
>  throw sg_io_exception("Failed to load 3D model:" +
> modelResult.message(),
>modelpath);
>  >   model = copyModel(modelResult.getNode());
>
> The object currently being expired in the ObjectCache doesn't seem to
> bear any relation to the model being loaded; one is a windsock and the
> other a radio tower.
>
> This is after I changed all of the osg::getSomething into
> osg::getRefSomething.
>
> I'm now a little confused as I was sure that the fix would work; I've
> kept the debug session open in case there is anything that I need to
> inspect.
>
>
> ___
> 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

Re: [osg-users] Deleting still referenced object

[Richard Harrison]

On 15/01/2019 09:03, Robert Osfield wrote:


illustrated it well) and I'm currently flying one of my long test routes.

Fingers and toes crossed.


..and alas after 30h I've got a similar looking problem; the pattern is 
the same i.e. DatabasePager loading something whilst ObjectCache is 
expiring.


This time it's a segfault in the DatabasePager during a copy of a model 
that has just been loaded (simgear, SGReaderWriterXML.cxx:342)


    options->setDatabasePath(texturepath.local8BitStr());
    osgDB::ReaderWriter::ReadResult modelResult;
    modelResult = osgDB::readRefNodeFile(modelpath.local8BitStr(), 
options.get());

    if (!modelResult.validNode())
    throw sg_io_exception("Failed to load 3D model:" + 
modelResult.message(),

  modelpath);
>   model = copyModel(modelResult.getNode());

The object currently being expired in the ObjectCache doesn't seem to 
bear any relation to the model being loaded; one is a windsock and the 
other a radio tower.


This is after I changed all of the osg::getSomething into 
osg::getRefSomething.


I'm now a little confused as I was sure that the fix would work; I've 
kept the debug session open in case there is anything that I need to 
inspect.



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Robert Osfield]

HI Richard,

On Tue, 15 Jan 2019 at 00:16, Richard Harrison  wrote:
> I've just changed simgear (again thanks for the code, that really
> illustrated it well) and I'm currently flying one of my long test routes.

Fingers and toes crossed.

> Is there any other documentation of things that are deprecated?

If a method or class is deprecated then there will be a doxygen
comment beside the method/class.  Some places might not have been
tagged as deprecated but still have a better alternative - if we spot
these we'll just need to add them one by one.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Richard Harrison]

Thanks Robert and Laurens for your responses.

It all makes a lot of sense and it is the solution that I was looking 
for all along but failed to find because I didn't look hard enough even 
though I should have been able to figure it out - so thanks for the 
guidance. Most of my effort went into identifying the problem; the fix 
was only a few hours.


I've just changed simgear (again thanks for the code, that really 
illustrated it well) and I'm currently flying one of my long test routes.



I will add a comment to the ObjectCache about getFromObjectCache()


good idea; that would have helped me; possibly even I could have tracked 
down the problem myself.




I would also recommend changing instances of
readNodeFile/readImageFile/readObjectFile() to readRefNodeFile() etc.


I've just had a quick search through OSG and these are the methods that 
I've found that I'll change if we're using them to be the ref versions. 
We've still got a few multithreading related problems to find and these 
may help.


readRefHeightFieldFile
readRefImageFile
readRefNodeFile
readRefNodeFiles
readRefObjectFile
readRefScriptFile
readRefShaderFile

Is there any other documentation of things that are deprecated?


All these Ref version for file loading and cache came in existence to
address threading issues.  In hindsight the OSG should never have
provided the non ref_ptr<> versions.


That's often the way; and hindsight is a truly wonderful thing.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Robert Osfield]

Thanks for chipping in Laurens.  I have just had a look at simgear and
the DefaultCachePolicy::find(const string& fileName, const Options*
opt) that calls registry->getFromObjectCache(fileName) is definitely
problematic.  the getFromObjectCache() method only passes back a C
pointer, not a ref_ptr<> and has been proven to cause threading
issues.  The ObjectCache::getRefFromObjectCache() is the replacement
for this unsafe method and should always be used in threaded
applications.

The DefaultCachePolicy::find(..) method is also problematic as it
passes back a C pointer as well, so it should be changed to pass back
a ref_ptr<> so that every step of the way the subgraph that is being
passed around remains with a positive ref count.

The recent PR for the OSG just shifts the timing so make the crash
less common, but the bugs are still there.  From 3.4 onwards the OSG
has the tools to prevent these problems, but with the old unsafe API's
still around for compatibility unfortunately users aren't forced to do
the right thing.

I did a quick checkout of simgear and had a bash at fixing this issue
but am getting compile errors on unrelated code. The code I would
change though would be:

// original and thread unsafe ModelRegistry.cxx :
osg::Node* DefaultCachePolicy::find(const string& fileName,
const Options* opt)
{
Registry* registry = Registry::instance();
osg::Node* cached
= dynamic_cast(registry->getFromObjectCache(fileName));
if (cached)
SG_LOG(SG_IO, SG_BULK, "Got cached model \""
   << fileName << "\"");
else
SG_LOG(SG_IO, SG_BULK, "Reading model \""
   << fileName << "\"");
return cached;
}

Suggested improvement:
osg::ref_ptr DefaultCachePolicy::find(const string& fileName,
const Options* opt)
{
#if OSG_VERSION_LESS_THAN(3,4,0)
osg::ref_ptr cachedObject =
registry->getFromObjectCache(fileName);
#else
osg::ref_ptr cachedObject =
registry->getRefFromObjectCache(fileName);
#endif

ref_ptr cachedNode =
dynamic_cast(cachedObject.get());
if (cached.valid())
SG_LOG(SG_IO, SG_BULK, "Got cached model \""
   << fileName << "\"");
else
SG_LOG(SG_IO, SG_BULK, "Reading model \""
   << fileName << "\"");
return cached;
}

Not the change to use ref_ptr<> where ownership is explicitly handled
and the use of ObjectCache::getRefFromObjectCache().

I will add a comment to the ObjectCache about getFromObjectCache()
being deprecated and not thread safe and give the recommendation of
changing to getRefFromObjectCache().

I would also recommend changing instances of
readNodeFile/readImageFile/readObjectFile() to readRefNodeFile() etc.
In the case of the SGReaderWRiterXML.cxx I'd change the line:

modelResult = osgDB::readNodeFile(modelpath.local8BitStr(),
options.get());

To:

modelResult =
osgDB::Registry::instance()->readNode(modelpath.local8BitStr(),
options.get());

As the ReadResult already has ref_ptr<> usage internally and is thread
safe already.

All these Ref version for file loading and cache came in existence to
address threading issues.  In hindsight the OSG should never have
provided the non ref_ptr<> versions.

Cheers,
Robert.

On Mon, 14 Jan 2019 at 10:55, Voerman, L.  wrote:
>
> Hi Richard,
> sorry to drop into the discussion so late, I think the problem is that you 
> should call
> getRefFromObjectCache
> instead of
> getFromObjectCache
>
> available in osg versions above 3.3.4, this should close the gap where the 
> refCount can touch zero.
> From your stack trace the call seems to come from the flightgear code:
>
> ot21-OpenThreads.dll!OpenThreads::Mutex::lock() Line 115 C++
> osg160-osgDB.dll!osgDB::ObjectCache::getFromObjectCache(const 
> std::basic_string,std::allocator > & 
> fileName, const osgDB::Options * options) Line 99 C++
> fgfs.exe!simgear::DefaultCachePolicy::find(const 
> std::basic_string,std::allocator > & 
> fileName, const osgDB::Options * opt) Line 724 C++
>
> Regards, Laurens.
>
> On Mon, Jan 14, 2019 at 8:28 AM Richard Harrison  wrote:
>>
>> On 11/01/2019 07:38, Robert Osfield wrote:
>> > If you are able to characterise what is going on then let me know and
>> > I may be able to help spot a solution.  Having a small example that
>> >
>> For some reason my last message doesn't seem to have made it to this
>> list; it's on the forum[1]
>>
>> I've diagnosed what I think is the problem, I've got a solution and I've
>> tested it; what I'm really after is confirmation that I haven't missed
>> something.
>>
>> This relates to pull request
>> https://github.com/openscenegraph/OpenSceneGraph/pull/690
>>
>> ---
>>
>> [1]
>> http://forum.openscenegraph.org/viewtopic.php?p=75443=f9ec59f5127e4760f6694c56b925f54a#75443
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> 

Re: [osg-users] Deleting still referenced object

[Voerman, L.]

Hi Richard,
sorry to drop into the discussion so late, I think the problem is that you
should call
getRefFromObjectCache
instead of
getFromObjectCache

available in osg versions above 3.3.4, this should close the gap where the
refCount can touch zero.
>From your stack trace the call seems to come from the flightgear code:

   1. ot21-OpenThreads.dll!OpenThreads::Mutex::lock() Line 115 C++
   2. osg160-osgDB.dll!osgDB::ObjectCache::getFromObjectCache(const
   std::basic_string,std::allocator > &
   fileName, const osgDB::Options * options) Line 99 C++
   3. fgfs.exe!simgear::DefaultCachePolicy::find(const
   std::basic_string,std::allocator > &
   fileName, const osgDB::Options * opt) Line 724 C++

Regards, Laurens.

On Mon, Jan 14, 2019 at 8:28 AM Richard Harrison  wrote:

> On 11/01/2019 07:38, Robert Osfield wrote:
> > If you are able to characterise what is going on then let me know and
> > I may be able to help spot a solution.  Having a small example that
> >
> For some reason my last message doesn't seem to have made it to this
> list; it's on the forum[1]
>
> I've diagnosed what I think is the problem, I've got a solution and I've
> tested it; what I'm really after is confirmation that I haven't missed
> something.
>
> This relates to pull request
> https://github.com/openscenegraph/OpenSceneGraph/pull/690
>
> ---
>
> [1]
>
> http://forum.openscenegraph.org/viewtopic.php?p=75443=f9ec59f5127e4760f6694c56b925f54a#75443
>
> ___
> 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

Re: [osg-users] Deleting still referenced object

[Richard Harrison]

On 11/01/2019 07:38, Robert Osfield wrote:

If you are able to characterise what is going on then let me know and
I may be able to help spot a solution.  Having a small example that

For some reason my last message doesn't seem to have made it to this 
list; it's on the forum[1]


I've diagnosed what I think is the problem, I've got a solution and I've 
tested it; what I'm really after is confirmation that I haven't missed 
something.


This relates to pull request 
https://github.com/openscenegraph/OpenSceneGraph/pull/690


---

[1] 
http://forum.openscenegraph.org/viewtopic.php?p=75443=f9ec59f5127e4760f6694c56b925f54a#75443


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Robert Osfield]

HI Richard,

On Fri, 11 Jan 2019 at 01:36, Richard Harrison  wrote:
> I'm a FlightGear core developer and I can confirm that this is something that 
> we know about and I'm trying to fix.

This month I'm working towards a 3.6.4 stable release, given that an
issue has been observed between 3.4.x and master there is reasonable
chance that it also exists in the 3.6 branch, so it would be good to
track down what is going on.

In the 3.6 release cycle we did track down some bugs related to the
object cache, the fixes should have made it into master.  I would be
worth checking the log for src/osgDB/ObjectCache.cpp for 3.4, 3.6 and
master to see if there is anything that needs to be ported between
these branches,

If you are able to characterise what is going on then let me know and
I may be able to help spot a solution.  Having a small example that
reproduces the problem would be ideal as this could then be used to
figure out the cause and confirm that it's finally fixed.

Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Richard Harrison]

Chris Hanson wrote:
> Ok. Is this a recent issue or do you know when it appeared? That's some 
> delicate code in there...


Yeah I noticed that there's some complex code and thread sensitive (i.e. 
delicate) stuff; it's taken me a long time to figure out what it's doing and 
why it is being done; and I'm being very careful with the changes I've made as 
experience tells me that it's ever so easy to make multi-threaded code worse 
whilst trying to make it better. Sometimes a fix to shared data isn't a fix 
even if it makes the problem go away, and I want to avoid doing anything stupid 
by careful analysis, testing and peer review.

The deleting whilst still in use as been happening occasionally for the last 
few years; but recently the frequency of user reports has increased which I 
think is probably because we are now shipping more scenery (based on OSM) that 
makes more use of shared models. 

Currently FG ships with a slightly modified OSG 3.4.1 and I'm building my 
FlightGear against master (c934172432cad368f5731ae5d682d7d6ecab7f48) and the 
problem is present in both versions. I'm still fairly sure that the reason is 
as outlined in my first post and that the fix appears to be working as 
expected. 

Once I'm happy with the fix, and after taking into account any advice or 
comments from here; I'll make a pull request.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75441#75441





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Chris Hanson]

Ok. Is this a recent issue or do you know when it appeared? That's some
delicate code in there...

On Thu, Jan 10, 2019 at 10:57 PM Richard Harrison  wrote:

>
> Chris Hanson wrote:
> > Due to the domain complexities, this is REALLY something probably the
> FlightGear community knows anything about.enegraph.org[/url]
> >
>
>
> I'm a FlightGear core developer and I can confirm that this is something
> that we know about and I'm trying to fix.
>
> Cheers
> --Richard
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=75439#75439
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@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  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Richard Harrison]

Chris Hanson wrote:
> Due to the domain complexities, this is REALLY something probably the 
> FlightGear community knows anything about.enegraph.org[/url]
> 


I'm a FlightGear core developer and I can confirm that this is something that 
we know about and I'm trying to fix.

Cheers
--Richard

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75439#75439





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Chris Hanson]

The high level app is FlightGear, an OSG-using flight sim.

Due to the domain complexities, this is REALLY something probably the
FlightGear community knows anything about.

On Thu, Jan 10, 2019 at 5:08 PM Robert Osfield 
wrote:

> Hi Richard,
>
> The info you've provided doesn't give us much to go on to understand
> what might be going on your system, we'll need a high level view of
> your platform, OSG version, OSG usage model etc.
>
> If you aren't already using 3.6.x then I'd strongly recommend
> upgrading as this will wrap up all the bug fixes made over the years,
> there isn't much point trying to investigate issues that already have
> been solved.
>
> Cheers,
> Robert.
>
> On Thu, 10 Jan 2019 at 15:41, Richard Harrison  wrote:
> >
> > I've now wired in the ReadWriteMutex and initial impressions are
> promising; each one of the "expired cannot check for expiry" is a potential
> gateway into the problem (assuming of course that I'm right about what the
> problem is).
> >
> >
> >
> > Code:
> > 165.86 [WARN]:OSGObjectCache::removeExpiredObjectsInCache
> expired cannot check for expiry as something is accessing the object cache
> >  165.89 [WARN]:OSGObjectCache::removeExpiredObjectsInCache
> expired cannot check for expiry as something is accessing the object cache
> >  176.60 [ALRT]:nasal  0 Transport
> >  176.68 [ALRT]:nasal  0 Transport
> >  176.74 [ALRT]:nasal  0 Railroad
> >  176.84 [ALRT]:nasal  0 Transport
> >  176.98 [ALRT]:nasal  0 Transport
> >  176.98 [ALRT]:nasal  0 Transport
> >  200.14 [WARN]:io
>  I:\flightgear\terrasync\Objects\w010n50\w004n56\LongannetChimney.png too
> small 1,128
> >  200.15 [WARN]:io
>  I:\flightgear\terrasync\Objects\w010n50\w004n56\LongannetChimney.png too
> small 1,128
> >  200.15 [WARN]:OSGObjectCache::removeExpiredObjectsInCache
> expired cannot check for expiry as something is accessing the object cache
> >
> >
> >
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=75425#75425
> >
> >
> >
> >
> >
> > ___
> > 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
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@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  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Richard Harrison]

On 10/01/2019 17:08, Robert Osfield wrote:

Hi Richard,

The info you've provided doesn't give us much to go on to understand
This is following on from my (somewhat lengthy) message[1] on 
2019-01-08, 00:15Z which has context at the start of that message, but 
for ease of reading it is as below.


>Using osg master; self built; application FlightGear; Win32 x64; MSVC 
2015.
>In FlightGear when OSG warning Warning: deleting still referenced 
object ... the final reference count was" is detected in our 
NotifyHandler we throw an exception (probably the only reliably thing to 
do, as this message generally comes before some sort of segfault).


I appreciate that when viewed out of context the recent message makes no 
sense as it's about my testing of the changes I've made to ObjectCache 
and DatabasePage to use a ReadWriteMutex to ensure that nothing is 
removed from the cache when the DatabasePager thread is in the process 
of adding a new model that references something in the object cache that 
has just expired.


The test is currently at 54.2 hours of flight time - and some 
perfunctory checks in the debugger show that the cache is being 
maintained (objects are expiring); and the message[2] "...cannot check 
for expiry as something is accessing the object cache" indicates that 
the object cache mutext check is working properly (the check uses 
tryLock so rendering performance isn't affected).


I'm still working on my assumption that my original analysis[1] is right 
and it is probably best viewed on the forum as the formatting wasn't 
nice when I posted to the list and I've since cleaned up the forum version.


-
[1] http://forum.openscenegraph.org/viewtopic.php?p=75436#75436
[2] I added the debug message "cannot check for expiry as something is 
accessing the object cache" to indicate that the object cache was 
waiting (tryLock) on the mutex

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deleting still referenced object

[Robert Osfield]

Hi Richard,

The info you've provided doesn't give us much to go on to understand
what might be going on your system, we'll need a high level view of
your platform, OSG version, OSG usage model etc.

If you aren't already using 3.6.x then I'd strongly recommend
upgrading as this will wrap up all the bug fixes made over the years,
there isn't much point trying to investigate issues that already have
been solved.

Cheers,
Robert.

On Thu, 10 Jan 2019 at 15:41, Richard Harrison  wrote:
>
> I've now wired in the ReadWriteMutex and initial impressions are promising; 
> each one of the "expired cannot check for expiry" is a potential gateway into 
> the problem (assuming of course that I'm right about what the problem is).
>
>
>
> Code:
> 165.86 [WARN]:OSGObjectCache::removeExpiredObjectsInCache expired 
> cannot check for expiry as something is accessing the object cache
>  165.89 [WARN]:OSGObjectCache::removeExpiredObjectsInCache expired 
> cannot check for expiry as something is accessing the object cache
>  176.60 [ALRT]:nasal  0 Transport
>  176.68 [ALRT]:nasal  0 Transport
>  176.74 [ALRT]:nasal  0 Railroad
>  176.84 [ALRT]:nasal  0 Transport
>  176.98 [ALRT]:nasal  0 Transport
>  176.98 [ALRT]:nasal  0 Transport
>  200.14 [WARN]:io 
> I:\flightgear\terrasync\Objects\w010n50\w004n56\LongannetChimney.png too 
> small 1,128
>  200.15 [WARN]:io 
> I:\flightgear\terrasync\Objects\w010n50\w004n56\LongannetChimney.png too 
> small 1,128
>  200.15 [WARN]:OSGObjectCache::removeExpiredObjectsInCache expired 
> cannot check for expiry as something is accessing the object cache
>
>
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=75425#75425
>
>
>
>
>
> ___
> 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

Re: [osg-users] Deleting still referenced object

[Richard Harrison]

I've now wired in the ReadWriteMutex and initial impressions are promising; 
each one of the "expired cannot check for expiry" is a potential gateway into 
the problem (assuming of course that I'm right about what the problem is).


 
Code:
165.86 [WARN]:OSGObjectCache::removeExpiredObjectsInCache expired 
cannot check for expiry as something is accessing the object cache
 165.89 [WARN]:OSGObjectCache::removeExpiredObjectsInCache expired 
cannot check for expiry as something is accessing the object cache
 176.60 [ALRT]:nasal  0 Transport
 176.68 [ALRT]:nasal  0 Transport
 176.74 [ALRT]:nasal  0 Railroad
 176.84 [ALRT]:nasal  0 Transport
 176.98 [ALRT]:nasal  0 Transport
 176.98 [ALRT]:nasal  0 Transport
 200.14 [WARN]:io 
I:\flightgear\terrasync\Objects\w010n50\w004n56\LongannetChimney.png too small 
1,128
 200.15 [WARN]:io 
I:\flightgear\terrasync\Objects\w010n50\w004n56\LongannetChimney.png too small 
1,128
 200.15 [WARN]:OSGObjectCache::removeExpiredObjectsInCache expired 
cannot check for expiry as something is accessing the object cache



--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75425#75425





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org