#1998 MacOS FG always terminates unexpectedly

[Wopke Postuma-Bijl]

Hi, FG always crashed upon existing but also when in the middle of the program, for instance when I change my view. Of course this is rather vague, so I would be happy if someone could point out to me where to find an error log that I can attach to this ticket.

[James Turner]

When it crashes, there should be a 'details' button, you can copy the full text (it will be huge) from that and paste them here.

[Fahim Dalvi]

I've been encountering a similar case, and it is much more frequent in dense scenery areas - I've tried to take a look at the stack traces but they are rather different everytime. What would you suggest, should I keep collecting all of these and upload them here as attachments as I encounter them? Or should I try to recreate them consistently and only then post the consistently crashing cases?

[James Turner]

Please collect a representative sample, yeah - maybe not /all/ of them but certainly up to 10 or 20 would be good.

And, sorry for the crashes :(

[Fahim Dalvi]

Here is one I can recreate with 100% accuracy everytime:

./fgfs --fg-root=/Applications/FlightGear.app/Contents/Resources/data/ --airport=KSFO --aircraft=c172p --timeofday=noon

(The only aircraft I've not been able to reproduce the error on is the UFO, but all others I tried lead to a crash with the following stack trace:

0   org.flightgear.FlightGear       0x00000001032957ce 0x102c4e000 + 6584270
1   libosg.131.dylib                0x000000010498f945 osg::NotifyStreamBuffer::sync() + 85
2   libosg.131.dylib                0x00000001048b4558 std::__1::basic_ostream<char, std::__1::char_traits<char> >::flush() + 88
3   libosg.131.dylib                0x00000001049ac408 osg::Referenced::~Referenced() + 424
4   libosg.131.dylib                0x000000010493158e osg::Group::~Group() + 14
5   libosg.131.dylib                0x00000001049ac5ab osg::Referenced::signalObserversAndDelete(bool, bool) const + 267
6   libosgDB.131.dylib              0x00000001043bda60 std::__1::__tree<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::pair<osg::ref_ptr<osg::Object>, double> >, std::__1::__map_value_compare<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::pair<osg::ref_ptr<osg::Object>, double> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::pair<osg::ref_ptr<osg::Object>, double> > > >::erase(std::__1::__tree_const_iterator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::pair<osg::ref_ptr<osg::Object>, double> >, std::__1::__tree_node<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::pair<osg::ref_ptr<osg::Object>, double> >, void*>*, long>) + 144
7   libosgDB.131.dylib              0x00000001043bd048 osgDB::ObjectCache::removeExpiredObjectsInCache(double) + 216
8   libosgViewer.131.dylib          0x000000010476eaab osgViewer::Viewer::updateTraversal() + 363
9   libosgViewer.131.dylib          0x000000010477439d osgViewer::ViewerBase::frame(double) + 109
10  org.flightgear.FlightGear       0x0000000103293fbe fgOSMainLoop() + 126
11  org.flightgear.FlightGear       0x0000000103303f0f fgMainInit(int, char**) + 5279
12  org.flightgear.FlightGear       0x0000000102c58072 main + 290
13  org.flightgear.FlightGear       0x0000000102c57d64 start + 52

It only happens at dark hours, so I suspect this has something to do with extra light objects or so. Let me know if you want me to start a separate ticket for this, or post it ot he mailing list/forum directly for better visibility!

P.S. On another note, the majority of the crashes I've seen so far seem to always end up in some OSG function, not sure if thats useful information.

[xDraconian]

There is not much information to troubleshoot this issue.
The stacktrace implies the following scenario:
An object in the OSG cache has expired, so it is being unloaded.
Objects are cleaned up properly.
The IO stream is flushed and then the StreamBuffer is being sent a notification.
This notification is where the crash is happening.
The exception that occurred was not provided, but I'm assuming it was a SegFault.

Situation = Dark with extra light objects. This could be a good clue.
One possibility is a buffer overflow.

It would be good to collect additional details, such as the airport you were near when the crash occurred and what aircraft you were flying.

[James Turner]

Checking on old bugs: if anyone still experiences this, please let us know, otherwise I'll mark this one as expired.

[legoboyvdlp]

Expired