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

If you experience FlightGear crashes, please report a bug using the issue tracker (can be also used for feature requests).
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.

Re: 3.4 and the pain begins ...

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

not disagreeing with the general notion that git bissect would help - but that can be very tedious and time-consuming unless you have some semi-automated (scripted) way for running a test flight and logging all stats (memory consumption) to a file for each commit.

Given what we know already, I think that it would be better to just post your AS logs here, or if you really want to do git bissect, check the git logs first to focus on commits actually touching the RM component (I don't think there were that many commits ...)

Personally, I would prefer AS though, because it won't take as long - with git bissect, you would need to create a flight plan/pre-recorded flight that reliably reproduces the problem, then come up with a fgfsrc disabling most other features, starting up with an aircraft/location to execute the flight and watch the process or still use AS for detailed info on memory usage.

And even once you have all this in place, it's then rebuilding FG that becomes the bottleneck

EDIT: But if you want to use bissect, I'd tell bissect to focus on RM related sources via something like git bisect start -- Navaids Autopilot Airports which should cover all main sources relating to the RM

Obviously, that will not cover bugs in underlying APIs, i.e. stuff exposed to scripting space or lower-level C++ APIs (think smart pointers). So AS is more likely to give us immediate results.
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: 3.4 and the pain begins ...

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

I reckon it's in this commit. I checked out 18:00 on the 18th Dec and memory is stable. I checked out 10:00 on the 19th Dec and memory rises.

https://gitorious.org/fg/flightgear/com ... 86a465c002

The advantage of a human bisect, is that one can make educated guesses. I can post a log of results if you wish, but I'm reasonably confident the problem is in there. AS didn't flag any problems when I ran it on next but that could just mean large memory structures are being allocated rather than references being lost.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 11:57 am
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: 3.4 and the pain begins ...

Postby Hooray » Wed Feb 25, 2015 7:34 pm

ok, that commit touches a few more folders than I would have looked at given the RM focus we've been working with so far ...
You said it's roughly 180 MB/hr, so about 3 MB per minute.
You also said that you didn't have to actually use the RM, right ?
That would suggest that it's something at the ctor/initialization level.

The good thing is that you seem to have it narrowed down already, and that the corresponding code has an actual owner who is an active core developer.
So if in doubt, I'd suggest to post a follow-up to the devel list and/or the issue tracker so that Zakalawe (James) can take a look.

Otherwise, I'd be inclined to look at any raw pointers allocating via new() next - at first glance, I find the routePathPrivate stuff suspicious (see routePath.cxx, two ctors there) which doesn't seem to be using SGReferenced/SGSharedPtr or any other smart pointers: https://gitorious.org/fg/flightgear/sou ... th.hxx#L65

To see if that's a red herring or not, I'd suggest to modify the ctor by adding a SG_LOG(SG_GENERAL, SG_ALERT, "allocating new object") to each class to see what's going on when it's leaking, e.g.:
Code: Select all
SG_LOG(SG_GENERAL, SG_ALERT, "Allocating: " __FUNCTION__ " at: " __FILE__ << std::endl);


This added to all 3-5 classes modified in this commit should help nail down where objects keep being allocated (if in doubt, modify the dtor's equally) - so far, I'd guess that it's related to the RoutePath stuff and it not using smart pointers anywhere (as far as I can see...) - but it would be best for James to take a look at this.
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: 3.4 and the pain begins ...

Postby sanhozay » Wed Feb 25, 2015 8:15 pm

Hooray wrote in Wed Feb 25, 2015 7:34 pm:You said it's roughly 180 MB/hr, so about 3 MB per minute.

On a simple test route with an origin, destination and one intermediate waypoint, yes. With a more realistic route that I tried originally (SBGL - SAEZ with 18 intermediate waypoints), it was about 1Gb per hour.

You also said that you didn't have to actually use the RM, right ?

The memory started to climb after I programmed and activated the route. I didn't have to actually follow it and have it transition from one waypoint to another (apart from the initial transition from origin to first waypoint).

I'd suggest to post a follow-up to the devel list and/or the issue tracker so that Zakalawe (James) can take a look.

I just want to do another test, checking out that commit by number rather than using a date range. Just to be certain.

Otherwise, I'd be inclined to look at any raw pointers allocating via new() next - at first glance, I find the routePathPrivate stuff suspicious (see routePath.cxx, two ctors there) which doesn't seem to be using SGReferenced/SGSharedPtr or any other smart pointers: https://gitorious.org/fg/flightgear/sou ... th.hxx#L65

Unfortunately (or should that be fortunately), my knowledge of C++ is very limited.

but it would be best for James to take a look at this.

I'm inclined to agree. Let me do my final test and I'll update on the mailing list.

Thanks for your help.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 11:57 am
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: 3.4 and the pain begins ...

Postby Hooray » Wed Feb 25, 2015 8:37 pm

I think you're right - I just checked everything using the minimal startup profile using a fresh build of SG/FG:

  • ogel above pacific (MP, ai, weather, ALS etc disabled)
  • rendering of terrain/scenery and all other models completely disabled
  • route manager programmed from KSFO->KOAK with ~5 intermediate waypoint, and activated
  • added debugging statements to log ctor/dtor calls
  • sim time accelerated to 32x

I am seeing RoutePathPrivate objects being created regularly, with a bunch of WayptData instances each - but never seeing the destructor getting called for RoutePathPrivate objects, which would seem to confirm our previous working theory that the way RoutePathPrivate is used, is probably the culprit. At the very least, this should provide a good starting point for Zakalawe to have a look.

Here, it started with ~640 MB, and it's now already approaching 750 MB using the above settings in under 5 minutes (sim time being acccelerated). Memory utilization does seem to stop growing when the simulator is paused, but is otherwise not affected by anything else:

Code: Select all
new RoutePathPrivate:

WayptData

~WayptData

WayptData

~WayptData

~WayptData

WayptData

~WayptData

~WayptData

~WayptData

WayptData

~WayptData

WayptData

~WayptData

~WayptData

~WayptData

~WayptData

~WayptData

WayptData

~WayptData



So in all fairness, it seems that Jabberwocky wasn't entirely wrong here - despite his choice of words/language 8) Obviously, this could have been detected much earlier if people had bothered to test RCs or get snapshots from the build server ... most developers don't have time to thoroughly test features for hours...
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: 3.4 and the pain begins ...

Postby sanhozay » Wed Feb 25, 2015 9:48 pm

Good to see you have confirmed the problem.

These are the results of my final test, and are pretty conclusive. This was a 30 minute run on a realistic flight plan from SBGL to SAEZ with 20 waypoints total. I checked out the commit of the 18th Dec for the first run with a clean and build, then checked out the first commit of the 19th Dec and rebuilt.

Commit df61dfe1b33a254a828a947beb3086bd14ed9092
Code: Select all
$ while true; do ps -o size $(pgrep fgfs) | tail -1; sleep 60; done
530704
531772
532044
532044
532044
532044
532044
532044
532044
532044
532492
532492
532492
532492
532492
532756
532888
532888
533020
533020
533020
533020
533020
533020
533020
533020
533020
533020
533020
533020


Commit 7317aff22d393a5aaef6b5e84571fb86a465c002
Code: Select all
$ while true; do ps -o size $(pgrep fgfs) | tail -1; sleep 60; done
528608
552064
581004
672720
696656
721852
812100
839360
875892
914112
951012
989080
1026928
1059888
1101424
1139572
1177812
1215124
1253904
1291284
1329072
1367396
1404684
1442844
1480880
1518212
1556960
1594304
1671084


This is a growth of over 2GB/hour:

Code: Select all
$ bc -q
(1632172 - 1594304) * 60
2272080


So it appears that the growth per hour increases with the number of waypoints. The longer the flight, the more likely it is to have more waypoints.

People do keep updated with Git and check release candidates. I update every few days, but this has escaped me because I've not been doing long route manager flights since Christmas. Was there an announcement anywhere that indicated there were major changes to the route manager in the 3.4 RC? I think it would be helpful if users who do test could be pointed to tender areas when the RC comes out, or on an ongoing basis for people who run the Git version.

Note that the problem was reported at the start of February:

viewtopic.php?f=68&t=25325

It just didn't turn out very productively ;)
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 11:57 am
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: 3.4 and the pain begins ...

Postby Hooray » Thu Feb 26, 2015 2:26 am

sanhozay wrote in Wed Feb 25, 2015 9:48 pm:Good to see you have confirmed the problem.


To look at the underlying C++ code, you only need to understand how constructors and destructors work: a class constructor is invoked whenever a new object is created, it's typically a method having the same name as the class itself without any return type associated - e.g:
Code: Select all
class Foo {
 Foo() {} // embedded/inline constructor
};

// or separate constructor
Foo::Foo() {}


Equally, the destructor is invoked whenever objects get destroyed (freed), the name is simply the class name prefixed with a tilde character:
Code: Select all
class Foo {
 ~Foo() {} // embedded/inline constructor
};

// or separate constructor
Foo::~Foo() {}


The standard mechanism for making FlightGear "log" stuff to the console (or log file) is using the SG_LOG() macro, commonly using this:

Code: Select all
SG_LOG(SG_GENERAL, SG_ALERT, "my MESSAGE");


In conjunction, these 3 pieces of info give us everything to track allocation/de-allocation of RoutePath related classes, i.e. by either adding or modifying the corresponding constructors/destructors to make them echo stuff to the console using the SG_LOG() macro.



So it appears that the growth per hour increases with the number of waypoints. The longer the flight, the more likely it is to have more waypoints.

yeah, that would make sense - my ballpark calculations were also using the assumption that a number of structs/classes kept being allocated (and referenced) without ever being freed - so the the longer the route (as in waypoints), the more leaking going on - even though, the distance of the route doesn't matter as much, it's more about number of waypoints and time spent running apparently.


People do keep updated with Git and check release candidates. I update every few days, but this has escaped me because I've not been doing long route manager flights since Christmas. Was there an announcement anywhere that indicated there were major changes to the route manager in the 3.4 RC? I think it would be helpful if users who do test could be pointed to tender areas when the RC comes out, or on an ongoing basis for people who run the Git version.


I guess that would be best discussed on the devel list - ideally, people doing such flights regularly would provide a corresponding "fgtape" file using a standard aircraft and get this committed to $FG_ROOT into some kind of "Tests" directory containing pre-recorded flights for doing regression testing in an automated fashion. The thing to keep in mind here is that those among us able (and willing) to troubleshoot such issues are most unlikely to ever actually use FlightGear like this, which certainly includes Zakalawe. Thorsten recently also mentioned that he'll typically just start up FlightGear a few dozen of times using a simple aircraft to test things, without really doing any "real" flying at all. So there are certainly a number of use-cases that aren't getting much attention unfortunately.
Which is why it would be a good idea for people to provide flight recorder tapes covering use-cases they care about, and get those committed to fgroot (fgdata) - so that we can grow a library of useful flights to do regression testing - as long as those flights are using standard aircraft and features, they should also be useful for people entirely new to FlightGear.

While developers, and power users, could use those flights to run FG in an unattended fashion, without having to be overly familiar with aircraft internals (think aircraft startup procedures, IAPs, STARs and other VA stuff) - we could even use accelerated sim-time to complete whole flights in a fraction of the time normally required, while stress-testing a bunch of underlying systems, including the route manager, autopilot, and FDM. Many of those don't necessarily require any "rendering" - which is touching on the whole "headless" effort that James has been working towards independently: http://wiki.flightgear.org/FlightGear_Headless

So as you can probably tell, there's certainly some momentum here, it just takes people to get this started - i.e. by providing said flight recorder tapes and getting them committed to the base package, while offering to maintain/update them in the time to come - ideally, also showing a willingness to do regression testing in the form you've shown here.
At some point, this could then even be done in an automated fashion on the build server directly - but we will need people to provide fgtape files covering different use-cases to exercise different code paths, without core developers necessarily having to spend hours doing transcontinental flights in a twin-engine turbprop, you know :mrgreen:

But I guess that is something that should be better discussed on the devel list, once we have people offering to provide a few pre-recoreded fgtape files to get this started ...


Note that the problem was reported at the start of February:

viewtopic.php?f=68&t=25325
It just didn't turn out very productively ;)


I looked at the thread again, and I do remember it - it wasn't obvious to me that the OP also stated somewhere that he was using the route manager, but like I said I was skeptical about some conclusions drawn there. And regarding Thorsten's conclusions specifically: he's a rendering guy, and primarily interested in visual stuff, especially scenery/terrain - so with his background, it is normal that everything looks like a terrain/scenery related issue to him - i.e. law of the instrument: if your only tool is a hammer, everything looks like a nail :D

Frankly, Thorsten is usually right - and unfortunately he's pretty aware of this circumstance :lol: , so he can be rather compelling even when he's very wrong, and most people don't bother responding to him then, because it is taking too much time and energy to argue with someone so elaborately...

We've had the same discussions about subsystem-level memory tracking in the TerraGear LOD thread, where Thorsten also strongly disagreed with the notion that this would have helped identify certain issues much earlier (including this one by the way).

In retrospective, it is unfortunately true that most of us (including myself ...) have repeatedly suggested workarounds to lower overall resource utlization instead of looking at identifying the underlying culprit for resource leakage elsewhere - which also includes the whole "reverting back to WS 1.0" advice, but also the leaking listeners issue Torsten and Rebecca fixed a whole ago. So there isn't just uninformed end-users, there are also uniformed contributors coming up with pathetic excuses for FlightGear's lack of explicit resource management...
The PagedLOD stuff is obviously great, but it only affects renderings - more specifically, only scenery/terrain, anything outside these domains isn't affected, which includes 99% of all other SGSubsystems in FlightGear, most of which aren't even yet making use of smart pointers ... (as can be see by this issue now).

So, basically, given FlightGear's growing complexity, what is needed is a dedicated means for OPTIONALLY tracking resource utilization based on subsystems/features, i.e. in terms of RAM/CPU and GPU/VRAM utilization, which -in conjunction with a community-grown library of use-cases (think flight recorder tapes)- could then be used to run FlightGear regression tests in a semi-automated and unattended fashion to gather statistics that don't leave much room for speculation.

So I guess it would be best to look forward and just try to find a way to prevent such misunderstandings in the future, and allow other contributors to draw conclusions without having to be intimately familiar with the C++ code of each component in FlightGear, i.e. by coming up with benchmarks and test-cases that people care about and get those committed to fgdata, so that developers can use those for benchmarking FG performance - even completely unrelated to scenery/terrain or visuals in particular.
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: 3.4 and the pain begins ...

Postby Thorsten » Thu Feb 26, 2015 6:26 am

I looked at the thread again, and I do remember it - it wasn't obvious to me that the OP also stated somewhere that he was using the route manager, but like I said I was skeptical about some conclusions drawn there. And regarding Thorsten's conclusions specifically: he's a rendering guy, and primarily interested in visual stuff, especially scenery/terrain - so with his background, it is normal that everything looks like a terrain/scenery related issue to him - i.e. law of the instrument: if your only tool is a hammer, everything looks like a nail


In all due fairness, I never drew any conclusions in this thread. It stalled already at the point where I pointed out that memory usage has many confounding factors and we need much more information to draw some conclusions.

I hold to the notion that 'Is it normal that FG uses X GB of memory' isn't anywhere meaningful unless we know things like visibility, location, object density, from where to where you flew...

My actual conclusion was

The point is that if you want to learn something, you need to set up a benchmark test situation. Note the quantity you're interested in. Change one setting. Repeat the benchmark. Make a table of what setting changed memory occupancy how. Then you know something.


or stated again later

Memory consumption is a complicated problem, and it depends on a number of variables. Which is what I try to explain to you so that you assemble information which actually means something. But apparently you want it to be simple, you already 'know' that something 'must be wrong' and you want me to confirm that. But I can't do that, because I understand that the problem is complicated.


I think you'll look in vain for any statement from my side that this is a scenery-related problem. I said several times I don't know what it is because I have insufficient information. As this thread here has demonstrated, once you manage to get rid of the confounding factors, you can find the source.

So, I'd very much appreciate that if you criticize me, you do it based on the facts.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: 3.4 and the pain begins ...

Postby sanhozay » Thu Feb 26, 2015 10:00 am

I can confirm that Zakalawe has fixed the memory growth issue:

This is my SBGL-SAEZ flight with 20 waypoints.

Code: Select all
$ while true; do ps -o size $(pgrep fgfs) | tail -1; sleep 60; done
1395336
1395336
1395336
1395336
1396496
1396496
1396496
1396496
1396496
1396496
1396496
1396496
1396496
1396496
1396496
1396496
1396496
1396496
1398412
1398412
1398412
1398412
1398412
1398412
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 11:57 am
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: 3.4 and the pain begins ...

Postby Hooray » Thu Feb 26, 2015 5:31 pm

Thorsten wrote:I'd very much appreciate that if you criticize me, you do it based on the facts.

@Thorsten: no need to have yet another discussion like this - but obviously I never disagreed with the statements you quoted above - what you conveniently omitted though, are your postings/statements which clearly stopped the thread from being fruitful, and which stopped the OP from working with us to find out what was going on.

And no, this is not about criticizing or attacking you - I think, you will find just as many responses where I did the same thing.

And this can be seen elsewhere, too -i.e. contributors suggesting a misconfiguration issue and coming up with a fancy explanation (or even formula...) for run-time behavior (look at F-JJTH's Rembrandt related postings suggesting that all people unable to run Rembrandt at >= 40 fps are "unable to configure their computer correctly").

There are some very real issues in FlightGear due to the way resource utilization is not managed explicitly - including parts of FG that are completely unrelated to scenery/terrain and rendering, features that are leaking resources - so posting a fancy formula to describe memory occupancy is one thing (posting a "plea for sanity" another), but claiming that this formula is covering all the buggy code that we have (and which obviously also still is added monthly) is very short-sighted (many of these bugs being in code paths that most of us don't even exercise in a typical test, as could be seen here...)

And we are doing a disservice to FG by behaving like that (with that particular thread, and your role in it, really just being an example).

So we should give end-users the benefit of the doubt, even if they don't hold multiple acadamic degrees or don't have have a track record of contributing to FG for over a decade.

We're alienating people - people who are making valid bug reports, by coming up with fancy technical explanations that ultimately turn out to be pathetic excuses for actual bugs.

As a community we should be able to do better than that hopefully, and yes, I am just as much part of this problem as others are.

I think we can learn from such incidents and try to come up with workflows, conventions and improvements to prevent them in the future - the question is, if we are willing to do exactly that, or prefer to keep fighting ...
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: 3.4 and the pain begins ...

Postby Thorsten » Thu Feb 26, 2015 6:08 pm

what you conveniently omitted though, are your postings/statements which clearly stopped the thread from being fruitful,


I'll invite you to cite any. I asked repeatedly for more information, said that I can't judge anything based on the information I have, and then explained why I need the information.

We're alienating people - people who are making valid bug reports, by coming up with fancy technical explanations that ultimately turn out to be pathetic excuses for actual bugs.


Sorry, but this is really crossing a line here. You might disagree with me, fine. You might disagree with my attempts and methods to trace and fix bugs, fine.

But I did not at any point offer a fancy technical explanation to cover a bug report. Nor did I prevent a thread from becoming productive. You're scoring some cheap points here from a very comfortable position - you're not responsible for anything that can break, you just sit back and give advice how things need to be done and tell us how bad we're doing every time something goes wrong. But if you want to make this a good guy, bad guy scenario by telling everyone what unreasonable things I have allegedly done, that's simply not acceptable. Please re-read the thread in question, and either give evidence for what you say or give me an apology.

If your methods of not alienating people is slandering others, then I'll have to give them a pass.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: 3.4 and the pain begins ...

Postby Hooray » Fri Feb 27, 2015 1:08 pm

all rhetoric aside, and to keep this constructive, I have now confirmation that the OP in that thread was indeed using the RM (which was NOT obvious to me at any point at all, so you could have been correct[*] just as well - the general point still holds though, that we should be able to do much better - including by the way NOT reading too much in between the lines ...)

I could go on an dissect your last posting word by word and pull out quotes from the archives, but I'd rather not - what good would it be ? I may send a PM once the dust has settled (or not), but there's no reason to take this personal - there's a reason why I used the terms "we" and ..."as a community".

I don't think it is too much to accept that, even without you -or anybody else- ever intending for that to happen obviously, the "standard explanation" you provided in the first response to that topic didn't address the issue adequately, and things quickly went haywire from then on.

[*] "correct" in terms of making the very first response you did, which did indeed distract from there actually being a bug. Without that obviously having been intended - but we're not necessarily dealing with developers when providing support on the forum
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: 3.4 and the pain begins ...

Postby Thorsten » Fri Feb 27, 2015 3:52 pm

but there's no reason to take this personal


You mean, no reasons except that according to you I personally clearly stopped the thread from being fruitful? Or that funny claim: so with his background, it is normal that everything looks like a terrain/scenery related issue to him - i.e. law of the instrument: if your only tool is a hammer, everything looks like a nail?

So you tell things about me which I've never said or done, and there's no reason to take this personal? You have been very personal in an unfair way, I take it such and I expect an apology for this from your side.

"correct" in terms of making the very first response you did, which did indeed detract from there actually being a bug.


Yes. Using the benefit of hindsight, you understand (as always) perfectly well what should have been done. Next time, try how good you are without that benefit. I'm very accurate in hindsight as well - as they say, hindsight is 20/20.

I don't think it is too much to accept that, even without you -or anybody else- ever intending for that to happen obviously, the "standard explanation" you provided in the first response to that topic didn't address the issue adequately


Well, in hindsight, no. In case it is necessary to admit the obvious: I wasn't blessed with the immediate insight into what the root cause was. I tried to start by answering the question whether 6 GB memory consumption are normal or not. Others asked for the relevant test data.

I re-iterate for the n-th time that later in the thread, I requested more information and gave explanations why that information is needed and what the relevant parameters are. Or how does this sound to you?

Quite so, but we don't know with what we're dealing with here. The mere fact that you observe a memory increase from takeoff to landing can be caused by any number of factors - visibility increasing through the flight, starting from the coast and flying into the continent or starting in a sparsely populated region into city terrain and a well-modeled airport will all do it. So will a memory leak in aircraft systems, increased AI traffic and a core leak.


Does this say 'Can't possibly be a memory leak?' or like 'Must be terrain related.' Or does this really say 'I don't know - could be all sorts of things.'

You can give me the benefit of doubt that I did this with the aim of finding out whether there is a bug rather than to torture an innocent user. Which I could not do because I wasn't given the information I needed from the OP who felt offended by these requests as I didn't immediately say 'FG is so buggy, must be a bug, I'll fix it, you're done, thank you'.

So, for the rest of us not trying to address problems after they've been solved - do you really think we should try to stop finding out whether there's a bug or not and start fixing something immediately? Do you think we should no longer explain the problem because it might be too complicated for the average user? Do you think telling the story that FG is so crappy because people can't get their act together will help fix any bug?

Or is the picture you painted of what happened in the thread simply a few miles off reality and in actual fact a more or less reasonable procedure was applied that could have led to the discovery of the bug a bit earlier if the OP hadn't been offended by being asked to provide more information?
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: 3.4 and the pain begins ...

Postby Jabberwocky » Tue Mar 03, 2015 2:24 am

I am so amazed by this kind of rethorics ... the OP aka me has clearly stated this problem, was RM related. Reading helps. But Hooray wanted me to run the rat race instead of reading and so the original info got drowned in his usual forum games. But fact is, everything that was actually needed was already in the first post. So, nice try, Hooray, now quit the games!
Jabberwocky
Retired
 
Posts: 1319
Joined: Sat Mar 22, 2014 7:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: 3.4 and the pain begins ...

Postby Hooray » Tue Mar 03, 2015 2:44 am

you didn't state you how arrived at the conclusion that this was indeed RM related, and even then, it would still make sense to independently verify any theory.
Unlike you Jabberwocky, sanhozay, was indeed able to come up with a reproducible test case, by following exactly the very "rate race" whose purpose is obviously eluding you entirely still.

There are no "games" involved here at all - making a bug report entails coming up with a reproducible test case so that others can independently verify the theory.
Which has nothing to do with the disagreement that Thorsten and I ended up having here.
.
Unlike you, sanhozay, provided such a test-case, based on our troubleshooting - and subsequently, I was able to pinpoint the exact nature of the bug, including the file, location (routePath constructor) and reason (lack of a smart pointer) - as well as "fix" for it (using a smart pointer).

All of this was solely based on sanhozay's troubleshooting: 1) his process memory stats and 2) the git commit he identified as likely culprit via git bissect - I would have stayed out of this, had sanhozay not posted those facts, and you would have down-graded your fgfs versions instead of getting involved in troubleshooting, like you stated yourself clearly:

Subject: 3.4 and the pain begins ...

Jabberwocky wrote: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.




Sorry, but just "you" stating that some subsystem seems related doesn't all of a sudden add any credibility/evidence to your statements - we needed exactly what sanhozay provided. Which is why the bug having been fixed, can be mainly credited to his troubleshooting - and not your posting, and neither Muller's in the other thread.
Developers need people willing and able to do proper troubleshooting, absent that, there's an intermediate group of people involved: contributors like Thorsten or myself, able to independently verify a bug report to see if there is problem or not, based on someone -like sanhozay- providing info, without necessarily having to understand C++.


Jabberwocky wrote:But fact is, everything that was actually needed was already in the first post.

You're entirely wrong with that, and while some of us ended up disagreeing about semantics of the other thread, you will undoubtedly have a hard time finding contributors supporting your notion of a proper, and complete, bug report.

Again, thanks for taking the time to report a bug - but if you want to learn how to do this properly, look at what sanhozay has done here, and especially watch his tone, and then compare this to your postings.

Besides, once again, it is your attention span (or reading skills) aparrently failing you here, because the "OP" reference above is referring to a completely different thread, and has nothing to do with you at all, as per sanhozay's posting, where he mentioned that the bug had been previously reported.
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Support

Who is online

Users browsing this forum: No registered users and 1 guest