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.
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
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
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,
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
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
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,
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++
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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]:OSG
23 matches
Mail list logo
