Board index FlightGear Support

3.4 and the pain begins ...

All general support: help on flying, installation, hardware, getting online etc. There are lots of users and developers to help you out.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?
- does the problem occur with any aircraft, at any airport?
- where did you download your aircraft/scenery from?
- is there any output printed to the console (black window)?
- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).

Please report any bugs not specific to an aircraft on the issue tracker.
To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

3.4 and the pain begins ...

Postby Jabberwocky » Tue Feb 24, 2015 8:35 pm

Hi,

I got force fed with FG 3.4, it came, together with a bunch of other updates while I was drinkinf coffee ... but fine. So, I did some little testing. It works fine if I just lfy around.

- as soon as I fly by Route Manager, it starts to suck memory as if there is no tomorrow. I made it in a 747 from Phoenis till about the middle of Utah till my 8 Gb were full. I was bound for Cairo ... well

- I find it also a bit sidturbing that other planes are virtuallly invisible if ther angle of view is not right. So you can't crash in them from the rear, but t-boning them because they are invisible to you is possible.

- the fps seem to be with the same planes and airports about 10% lower than in 3.2 but that needs more testing

- in compensation, the number of segment faults seems to be a lot higher (like 3 in the first hour).

- well, and TerraSync fails like usual and gave me already know only the infamous white clouds instead of terrain in two arrivals.

Maybe it's me, maybe it's just not my day ... but right now, I am quite unhappy with 3.4 and in three weeks, there is the USA Tour again, I want three bombers ready for that ... so I really lack a little bit the time for this kind of crash programming.

J.
Jabberwocky
Retired
 
Posts: 1316
Joined: Sat Mar 22, 2014 8:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: 3.4 and the pain begins ...

Postby Hooray » Tue Feb 24, 2015 9:12 pm

If you think you have found a bug, you are encouraged to report it at the tracker: https://code.google.com/p/flightgear-bugs/

Having a reproducible test case (settings, flight plan, pre-recordeded flight, fgtape) should help tremendously.

In general, it would make sense for you to create a flight plan that reliably reproduces the issue, and then change visibility/LOD to exclude scenery/terrain from being part of this, and then switch to another aircraft (i.e. ufo) to exclude the aircraft from being responsible.

So far, the route manager isn't yet known for being a resource hog leaking memory, so it makes sense to get your facts straight first - following the approach outlined above, should allow you to easily see what is contributing to the issues you're seeing (e.g. aircraft/scenery complexity).

That being said, people on Linux are encouraged to run FlightGear in a gdb session and actually post a backtrace, that is the most useful kind of info you can provide.
For details on doing that, please refer to: http://wiki.flightgear.org/Troubleshoot ... Backtraces


PS: Even if you should be able to provide very action-able information (as in, backtraces), it would also help to watch your language - none of the programmers involved in the last release cycle were intending for those crashes you're seeing to happen - and most likely they didn't show up for anybody else yet.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 3.4 and the pain begins ...

Postby sanhozay » Tue Feb 24, 2015 11:16 pm

I am also experiencing what looks like a memory leak in 3.5. I was trying to do a route manager flight from Rio to Buenos Aires today and the memory just climbed and climbed. I couldn't get past about 90 mins. I can't say it's definitely the route manager but I've done a lot of flying without it recently and not had any problems. Prior to that I did a lot of flying with the route manager and had no problems. I'm thinking it was ok in Dec and it's not now but that's just gut feeling at this stage.

I tried a couple of aircraft and the UFO on the same route and saw the memory climbing in all cases.

I've just checked out the 3.2 tags and I'll try the same flight after compiling. If that's ok, my plan is to start a git bisect.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: 3.4 and the pain begins ...

Postby sanhozay » Wed Feb 25, 2015 12:41 am

I checked out and compiled 3.2 (flightgear + simgear), flew the route (SBGL YLA MRC ...) and the process size was level by MRC. Not growing. Then I checked out 3.4, compiled and copied all my settings across before flying the same route in the same aircraft. I've just passed the same waypoint as on the 3.2 flight and the fgfs process is growing by around 1GB per hour.

Sampling process size for one minute (kilobytes)
Code: Select all
$ while true; do ps -o size $(pgrep fgfs) | tail -1; sleep 3; done
2296608
2297540
2298600
2299664
2300592
2301524
2302452
2303384
2304576
2305372
2306432
2307364
2308292
2309492
2310288
2311216
2312148
2313212
2314408
2315204

Calculate memory growth per hour (kilobytes)
Code: Select all
$ bc -q
(2315204 - 2296608) * 60
1115760
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: 3.4 and the pain begins ...

Postby Hooray » Wed Feb 25, 2015 2:56 am

ok, thanks for posting such helpful information - given that you are on Linux, could you use AddressSanitizer[1] to check where it's apparently leaking memory ?
If in doubt, please share your flight plan (the file) so that others can try to reproduce this with other subsystems (rendering/scenery) completely disabled.
For the sake of faster troubleshooting, you can also use time warp mode, to speed up simulation time.

[1]: http://wiki.flightgear.org/Troubleshoot ... sSanitizer
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 3.4 and the pain begins ...

Postby Jabberwocky » Wed Feb 25, 2015 4:25 am

That was an overlap ...

with Route Manager: ab. 90 minutes till memory full, but it seems to depend on the number of waypoints, I can do it faster if I put the waypoints nearer to each other and more in the fp.
without: Flying now for almost three hours without apparent memory leaks.
What I watched is, the big jumps appeared always at or after passing a waypoint.
Jabberwocky
Retired
 
Posts: 1316
Joined: Sat Mar 22, 2014 8:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: 3.4 and the pain begins ...

Postby Hooray » Wed Feb 25, 2015 4:34 am

Please try to create a flight plan that reliably reproduces the issue - next, disable scenery/terrain rendering using the draw masks to exclude scenery-induced memory occupancy from contributing to this. Next, use the ufo for flying the same flight plan to exclude the 747/777 as being too heavy. You can use the "time warp" feature to accelerate replays.

Alternatively, please provide an AddressSanitizer log file (as per the instructions above).

Thank you
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 3.4 and the pain begins ...

Postby Jabberwocky » Wed Feb 25, 2015 6:31 am

Actually, I consider just to go back to 3.2. I have three planes up till March 14th and other things to worry about. And the place where the issue occurs id pretty clear anyway. So, we can do the rat race for some days and end up in the same place, but since I am so narrow on time currently, I would really like to skip that.
By the way ... I was contacted on Mumble by people using Win 7 and Win 8.1 and FG 3.4 doesn't even start. Issues are exceptions 11 and 17 at start time. And the catalog leads still to a DNS error, so there is another well-defined glitch. Seems, 3.4 was not ripe to be released by all means. And before you, Hooray, jump on me again about bug reports and what not, I will not have several passwords and accounts for flightgear because the community is so split it can't create a one-stop portal.
Jabberwocky
Retired
 
Posts: 1316
Joined: Sat Mar 22, 2014 8:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: 3.4 and the pain begins ...

Postby sanhozay » Wed Feb 25, 2015 10:06 am

I've switched my test case to SBSV, runway 10, on the basis that flying east is purely over ocean tiles.

Aircraft is dh106 (De Havilland Comet), which is a pretty light model. Tracing process size begins on the runway, using the generic autopilot to set 210kts, 2000fpm and wings level. Trace in 1m intervals, measured in kB.

(3.4.0) Fly runway heading without touching the route manager
Code: Select all
$ while true; do ps -o size $(pgrep fgfs) | tail -1; sleep 60; done
1233840
1234376
1234652
1234652
1234652
1234652
1234652
1234652
1234652
1234652
1234652
1234652

(3.4.0) Fly route SBSV GIANT FACT using the route manager (roughly the same track as runway heading)
Code: Select all
$ while true; do ps -o size $(pgrep fgfs) | tail -1; sleep 60; done
1174476
1178384
1182224
1185272
1188328
1191512
1194700
1197888
1200928
1204244
1207284
1210468
$ bc -q
(1210468 - 1207284) * 60
191040

Although the initial size was smaller (which I can't explain), note the growth, which is around 190MB per hour.

(3.4.0) Fly runway heading then program and activate route manager (SBSV GIANT FACT) after 6 samples
Code: Select all
$ while true; do ps -o size $(pgrep fgfs) | tail -1; sleep 60; done
1243480
1243616
1243948
1243948
1243948
1243948
-------
1245672
1248984
1251912
1254968
1258540
1261588
$ bc -q
(1261588 - 1258540) * 60
182880

Note that I didn't need to follow the route, just activate the route manager. Process size was stable until the route manager was activated and then started to grow at around 180MB per hour.

I know 180MB doesn't sound much, but I I've seen that the leak is much larger when the route has more waypoints, as has Jabberwocky.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: 3.4 and the pain begins ...

Postby wkitty42 » Wed Feb 25, 2015 12:02 pm

Hooray wrote in Tue Feb 24, 2015 9:12 pm:If you think you have found a bug, you are encouraged to report it at the tracker: https://code.google.com/p/flightgear-bugs/

Having a reproducible test case (settings, flight plan, pre-recordeded flight, fgtape) should help tremendously.

In general, it would make sense for you to create a flight plan that reliably reproduces the issue, and then change visibility/LOD to exclude scenery/terrain from being part of this, and then switch to another aircraft (i.e. ufo) to exclude the aircraft from being responsible.

i had initially thought i might be seeing this problem with my 3.4.0 but it appears more to be that updating from terraserve is slow... no idea if that's solely due to my 3M DSL or not... when i read your post (that i'm responding to), i saved my route from KFLG to KATL... i had the route manager route it automatically for me when i first set it up... i've been using the UFO on this flight... several times i've had problems waiting on the scenery to load... it is like in The Langoliers when time has passed and the langoliers are coming in eating everything... i even downloaded TerraMaster and pointed it at my .fgfs/TerraSync directory so i could preload all the tiles on my route... according to TerraMaster, i did but FG either didn't like them or they weren't the right ones that FG wanted... after flying pretty much all day yesterday, i checked my memory use as another poster had mentioned... at that time FG was using just shy of 8Gig on this 16Gig system...

i've had to stop and reload a couple of times to get the scenery to come on in... i've no clue why and don't see anything obvious in my .fgfs/fgfs.log file which i have tailed during all flights and which i look at when it appears that i'm flying off the edge of the world... currently i'm between KOMMA and LIT at 6000 ft and having to stop occasionally to wait on the scenery... this after having to reload back at CRUSR, and DMINE... i'm starting to wonder if there's a comms problem with terraserve...

anyway, i though i'd toss that out there... especially the The Langoliers reference :lol:
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9148
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: 3.4 and the pain begins ...

Postby sanhozay » Wed Feb 25, 2015 4:09 pm

I tried to compile with the address sanitizer but it fails on the final link of fgfs:

Code: Select all
/usr/bin/ld: ../../3rdparty/sqlite3/libfgsqlite3.a(sqlite3.c.o): undefined reference to symbol 'pthread_mutexattr_settype@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status


@Hooray any suggestions?
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: 3.4 and the pain begins ...

Postby Hooray » Wed Feb 25, 2015 4:39 pm

according to google, that seems to be an ubuntu issue that may require changing the linking order:

http://stackoverflow.com/questions/8198 ... -on-ubuntu
http://askubuntu.com/questions/308863/c ... libc-2-2-5

not sure why you are seeing this now, but I guess that that the AS lib is confusing the linker - so I'd just try to switch it around with pthreads
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 3.4 and the pain begins ...

Postby sanhozay » Wed Feb 25, 2015 5:38 pm

OK, that did the job. Thanks.

For reference:

Code: Select all
cmake $FG \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_C_FLAGS="-fsanitize=address -fno-omit-frame-pointer -O2 -g -pthread" \
    -DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer -O2 -g -pthread" \
    -DCMAKE_SHARED_LINKER_FLAGS="-fsanitize=address -fno-omit-frame-pointer -O2 -g" \
    -DCMAKE_VERBOSE_MAKEFILE=1 \
    -DSIMGEAR_SHARED=ON \
    -DCMAKE_INSTALL_PREFIX:PATH="$FGFS_INSTALL"

On the first run, it aborted as soon as I opened any dialog, complaining about an alloc-dealloc mismatch in libplibpu.so, so I've turned that off:

Code: Select all
export ASAN_OPTIONS=alloc_dealloc_mismatch=0

I believe it should still report leaks.

I flew the SBSV GIANT FACT route and saw the memory climbing, but no messages during the test or after quitting Flightgear. According to the AddressSanitizer page:

LSan lies dormant until the very end of the process, at which point there is an extra leak detection phase. In performance-critical scenarios, LSan can also be used without ASan instrumentation.


But no messages about leaks. Which could mean:

a. It's allocating a lot of memory but not actually leaking it.
b. My executable isn't quite right
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: 3.4 and the pain begins ...

Postby Hooray » Wed Feb 25, 2015 5:48 pm

ok, that sounds good - and thanks for being so responsive here, as well as for being so willing to troubleshoot beyond just stating the obvious in a flaming way... :)

Also, the changes you've had to make should probably be added to the wiki to help others wanting to help with AS based testing - so unless anybody beats me to it, I will copy your last posting to the wiki later.

Like I said previously, once you are pretty sure that this is urelated to scenery and aircraft, using a simple model like the ufo/ogel should work reasonably well (ogel may work better with AP and RM as it's using a real FDM), with LOD settings really low, or all draw masks set to disable rendering. You can then accelerate sim time to speed up the execution of the flight, i.e. showing just the HUD.

It may obviously also help to disable other subsystems/features such as AI traffic, multiplayer, weather/ALS etc to end up with a really narrow test case.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 3.4 and the pain begins ...

Postby sanhozay » Wed Feb 25, 2015 6:26 pm

I still think it's a reasonable assumption that this a route manager problem, given that:

a. Memory size is flat without route manager activated
b. As soon as I activated the route manager, the memory started climbing

It may not be a memory leak, but if something is hanging onto an unbounded memory structure it's still a problem for anybody who wants to fly a long route using the route manager.

I've figured out how to go back to an intermediate snapshot between 3.2 and 3.4 to try and work out when the problem started. I'm doing it like this for flightgear and simgear before building:

Code: Select all
$ git checkout $(git rev-list -1 --before='Dec 1 2014' next)

It will take some time to do a manual bisect like this.

For some reason Flightgear crashes on this snapshot version as soon as I enable Terrasync, so I've started afresh with a clean ~/.fgfs directory and I'll just go without scenery.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Next

Return to Support

Who is online

Users browsing this forum: No registered users and 6 guests