Long-Range Flight Impossible?

[xsaint]

Hello mifi....

I had the same irritating problem here with my Ubuntu as well...even recompiling few times did not help.... the log files does not say much either....at times for me FG crashes the ENTIRE system...

and
Usually i realised just b4 FG crashes, the frame rate fells dramatically

To overcome, this is what i did...


1)Start FGRUN, on top left corner, select full screen mode with 800X600 display mode
2)Also change your bit rate from 32 bits to 24
3)Select you aircraft and go ahead with your game....
4)When you are in the game, go to View --> rendering
5)Now DISABLE shader and DISABLE 3d clouds

Now fly around... you will see that the frame rate improves dramatically...
And this has prevented some FG crashes lately

Now if this works for you as well, then what is the real problem initially?
Seems to me Display driver and FG may have some problems...
And/Or Malloc...memory allocations/kill problems?
these are just assumption

Anyway i Hope that helps.....

[mifi]

1)Start FGRUN, on top left corner, select full screen mode with 800X600 display mode
2)Also change your bit rate from 32 bits to 24
3)Select you aircraft and go ahead with your game....
4)When you are in the game, go to View --> rendering
5)Now DISABLE shader and DISABLE 3d clouds

I will give it a try and report here, but disabling the 3d clouds is not something I was hoping for. I like the clouds too much. They have improved dramatically lately and I really like them. sigh.

m

[xsaint]

1)Start FGRUN, on top left corner, select full screen mode with 800X600 display mode
2)Also change your bit rate from 32 bits to 24
3)Select you aircraft and go ahead with your game....
4)When you are in the game, go to View --> rendering
5)Now DISABLE shader and DISABLE 3d clouds

I will give it a try and report here, but disabling the 3d clouds is not something I was hoping for. I like the clouds too much. They have improved dramatically lately and I really like them. sigh.

m

It has to do with the shader then the 3d clouds actually....just to be safe, disable 3d clouds as well and when you know the performance is much better then before, you may enable 3d clouds and try again

cheers

[mifi]

1)Start FGRUN, on top left corner, select full screen mode with 800X600 display mode
2)Also change your bit rate from 32 bits to 24
3)Select you aircraft and go ahead with your game....
4)When you are in the game, go to View --> rendering
5)Now DISABLE shader and DISABLE 3d clouds

I will give it a try and report here, but disabling the 3d clouds is not something I was hoping for. I like the clouds too much. They have improved dramatically lately and I really like them. sigh.

m

Nope. Did not help. Still in 30 minutes.... it is gone.
Hmmm. Since the flight from KSFO to KLAX did work, I guess I can try to fly another route. Perhaps there is something weird in the scenery. I did notice in the Alps there are steep climbs that seem to be just one pixel wide.
Another thing to try is to get all command line parameters that fgrun generates and run fgfs under gdb with all those params.... if that would help. At this moment I am getting the latest software from CVS and recompile from that. To be continued...

m

[Gijs]

Try to run FlightGear without MP, without TerraSync and without AI (sim/traffic-manager/enabled=0). Especially the traffic manager is known for being buggish. If the problem does not appear with it disabled, we know that it is a TM problem...

[ChocBoy]

Gijs,


I can confirm that AI traffic is defintely a problem. I have disabled it for all of my recent flights, and I've been generally bug free! This is what I've been doing:

disable 3D clouds
no shaders
no shadows
no particles
no AI or ATC


and it's been doing a lot better! Try turning off AI stuff first, though. As the above bascially deletes the purpose of 2.0....

[kyokoyama]

What about the turnoff of different views, such as Flyby view? That worked in 1.9.1?

[simbabeat]

Ya go to view>view options and turn off views you don't need. Really turn off everything you will never use. That will make stuff go smoother.

[xsaint]

Without multiplayer mode, it tends to perform much better.....
Sadly it seems we have to disable so much features to have this version of FG to work....


cheers

[mifi]

Without multiplayer mode, it tends to perform much better.....
Sadly it seems we have to disable so much features to have this version of FG to work....

Indeed. It would be so much nicer if we could find the bugs and fix them. I will try to get a stack from gdb, but I yet have to manage getting a core file....
The problems we have do not seem to be incidents and will seriously limit the possibility of multiplayer events... sad, is it not?

m

[Vodoun da Vinci]

Something to keep in mind during this investigation is that the problems do not seem to affect all FGFS aficionados. I had many problems with "unknown exception" with 1.9.1 but have *never* had this with 2.0. I flew yesterday for over 3 hours on MP with AI enabled and every possible bell and whistle in FGFS running and never had a problem.

Luck maybe...but it might be more expedient to try and find out what the machines/OS that fail all have in common and what the machines/OS that aren't having issues all have in common. 'Cause I'm not convinced this is a bug in FGFS and not an incompatability/driver/OS specific issue.

"VooDoo" da Vinci

[mifi]

Without multiplayer mode, it tends to perform much better.....
Sadly it seems we have to disable so much features to have this version of FG to work....

Indeed. It would be so much nicer if we could find the bugs and fix them. I will try to get a stack from gdb, but I yet have to manage getting a core file....
The problems we have do not seem to be incidents and will seriously limit the possibility of multiplayer events... sad, is it not?

m

I have a stack backtrace that might help. I will try to generate more info.

Code: Select all

Program terminated with signal 11, Segmentation fault.
#0  std::string::_M_data (this=0xea119c0, ID=...)
    at /usr/include/c++/4.4/bits/basic_string.h:273
273         { return  _M_dataplus._M_p; }
(gdb) bt
#0  std::string::_M_data (this=0xea119c0, ID=...)
    at /usr/include/c++/4.4/bits/basic_string.h:273
#1  std::string::_M_rep (this=0xea119c0, ID=...)
    at /usr/include/c++/4.4/bits/basic_string.h:281
#2  std::string::size (this=0xea119c0, ID=...)
    at /usr/include/c++/4.4/bits/basic_string.h:624
#3  operator==<char> (this=0xea119c0, ID=...)
    at /usr/include/c++/4.4/bits/basic_string.h:2246
#4  FGTower::FindPlane (this=0xea119c0, ID=...) at tower.cxx:2271
#5  0x00000000004aa764 in FGTower::ReportDownwind (this=0xea119c0, ID=...)
    at tower.cxx:2374
#6  0x000000000049c4b5 in FGAIGAVFRTraffic::ProcessCallback (this=0xea119c0,
    code=1123555552) at AIGAVFRTraffic.cxx:411
#7  0x00000000004c2d16 in FGAIPlane::Update (this=0x1bda5d40,
    dt=<value optimized out>) at AIPlane.cxx:121
#8  0x000000000049b2fd in FGAILocalTraffic::Update (this=0x1bda5d40,
    dt=<value optimized out>) at AILocalTraffic.cxx:732
#9  0x000000000049d6cd in FGAIGAVFRTraffic::Update (this=0xea119c0, dt=0)
    at AIGAVFRTraffic.cxx:129
#10 0x0000000000494047 in FGAIMgr::update (this=0xe2f97d0,
    dt=<value optimized out>) at AIMgr.cxx:271
#11 0x000000000042f39c in fgMainLoop () at main.cxx:446
#12 0x00000000004795f2 in fgOSMainLoop () at fg_os_osgviewer.cxx:201
---Type <return> to continue, or q <return> to quit---
#13 0x000000000042e5c9 in fgMainInit (argc=17, argv=0x7fff42f81ec8)
    at main.cxx:951
#14 0x000000000042c42e in main (argc=17, argv=0x7fff42f81ec8)
    at bootstrap.cxx:229



m

[Jester]

Thanks for the backtrace. That crash is inside the (obsolete) AI local traffic code, which most of us have disabled a long time ago Especially when flying on MP, as AI traffic is confusing because it is not synchronized.

The problem itself is likely in AIMgr.cxx:

Code: Select all

        while(ai_list_itr != ai_list.end()) {
                FGAIEntity *e = *ai_list_itr;
                if(rs.size() && e->GetCallsign() == rs) {
                        //cout << "Removing " << rs << " from ai_list\n";
                        ai_list_itr = ai_list.erase(ai_list_itr);
                        delete e;
                        // This is a hack - we should deref this plane from the airport count!
                } else {
                        e->Update(dt);
                        ++ai_list_itr;
                }
        }


It is probably calling the Update on a plane already deleted. Uncommenting the "Remove" printout and adding the pointer value to the message, plus a similar one into the "Update" branch could help diagnose it:

Code: Select all

diff --git a/src/ATCDCL/AIMgr.cxx b/src/ATCDCL/AIMgr.cxx
index 8b6c448..02f5fdd 100644
--- a/src/ATCDCL/AIMgr.cxx
+++ b/src/ATCDCL/AIMgr.cxx
@@ -263,11 +263,12 @@ void FGAIMgr::update(double dt) {
        while(ai_list_itr != ai_list.end()) {
                FGAIEntity *e = *ai_list_itr;
                if(rs.size() && e->GetCallsign() == rs) {
-                       //cout << "Removing " << rs << " from ai_list\n";
+                       cout << "Removing " << rs << " (pointer " << e << ") from ai_list\n";
                        ai_list_itr = ai_list.erase(ai_list_itr);
                        delete e;
                        // This is a hack - we should deref this plane from the airport count!
                } else {
+                       cout << "Calling Update on pointer " << e << "\n";
                        e->Update(dt);
                        ++ai_list_itr;
                }


An alternate possibility is that the plane could be deleted somewhere else. For that, the FGAIPlane destructor invocation should be caught and the call chain examined.

[ChocBoy]

So, I guess we've concluded that you should disable AI traffic. That's the first step.

[ChocBoy]

Ok, AI is almost CERTAINLY the problem for me. I did an AVA flight and forgot to disable it, crashed three times. Then, did a test flight on my own: No crashes at all for 3 hours!