Out oF Memory surprise

Huh.

There must be more to it than my waffle.

I just tried a bunch of different scenarios at SCIR, for which I have 2 LC files by Giovanni Miduri: LC2643.bgl & LC2644.bgl. Memory use was stable each time. The pictures are taken after about 10 minutes sitting on the runway:

1. Base memory usage with no sim running

2. Both LC files in their own layer with no local texture folder

3. As above with a newly created empty local texture folder

4. Both LC files moved to Isla San Felix scenery layer containing VTP, LWM, AFD & mesh but no local texture folder

5. Both LC files moved to UK2000 EGDP scenery layer, with a populated local texture folder

6. User aircraft also at EGDP

The memory & CPU usage was stable and similar in each trial.

Defaid,

Was your memory usage not slowly creeping up, especailly in your number 5 test ? My wait was always between 0.5 and 1.0 hours before the OOM occurred and to pass the time during such long periods I often went out shopping or so because watching my screen for such long periods gave me rectangular eyes and serious patience problems. Moreover, my CPU usage was constantly up near 100%, while your's seem to remain pretty normal. Different types of LC files maybe ?

Hans

It might be easier to track the memory usage of the FS9 process in details, rather than overall system memory usage. Hitting the limit for a 32-bit process is what triggers this, not an overall situation where the OS runs out of memory.

Cheers!

Hi.

I'll run number 5 again (maybe tomorrow) and leave it for a couple of hours.

I just had a quick look with resource monitor instead of task manager and my CPU usage was steady at 34%. One core is at 100% and the others are almost idle.

Following Luke's suggestion, for scenario 5 FS9's working memory increased by about 30 MB in 15 minutes but a (very) quick check showed something similar when the two LC files were back where they should be.

I wasn't aware that there are different types of LC file. What were the three files or downloads that caused the OOM?

D

Well... result.

I'm sorry it took so long but I wanted to compare the bad layer/folder structure with the supposedly correct one. I ran test 5 and test 2 again.

It turns out that my PC is not strictly immune. It's just that the increased use of memory is so slow as not to cause any problem.

With the two landclass BGLs in a layer that includes a populated texture folder but no appropriate texture file, the bug takes up an extra 2.1 MB per minute. So if you have a local texture folder without the correct texture in it, then regardless of what other textures are in that folder, the bug will be triggered.

What's the limit? 2 or 4 GB? It's either 16 or 32 hours to crash, which may explain why it isn't an issue for everyone.

With the two BGLs in their own landclass layer (no texture folder), there was no memory leak. In fact, FS9 had unloaded a few kilobytes.

D

Bad structure, start:

Bad structure after two hours:

Own layer and no texture folder, start:

And own layer after two hours:

Defaid,

I'm happy that you were able to confirm my reasoning behind the cause of at least, some OOMs.

In the meantime I've also been doing targeted tests under different conditions, e.g. with single LC BGLs now purposely being inserted into different active airport scenery folders.

As a result it now seems that the creeping up speed of memory usage and the time it takes for the OOM-crash to appear, is dependant on the number of such LC BGLs present in those different and active (test) airport scenery folders.

Anyway, my system now seems to be at rest after removing the offending LC BGLs and placing them back into their dedicated "Land Class" scenery folder ..... without a texture folder. My LC folder now contains 1120 BGL files but I must admit that it also remains possible that some Mesh BGLs have somehow managed to slip into that folder as well. However, this should not cause any problems because Mesh BGLs do not call for any textures and have almost the same scenery priority layer anyway.

My dedicated Mesh scenery folder consists of 433 BGLs but with no texture folder either.

Regards

Hans

Programming expert(s) needed,

If we could all agree that LC BGLs situated within normal scenery folders, are the basic cause of (delayed) OOMs, then in my vision it should be possible to search for them via their unique properties and to then list them, together with the folder names within which they were found.

In this way such potential time bombs can be defused by moving them to their own specific LC folder with a far lower scenery priority.

I'm sadly not a programmer of any kind myself and would not even know where to begin but if any of you experts would be so kind as to make such a program and to post it, it would certainly be strongly appreciated, in any case by FS9 diehards like me. Could possibly also work for later FS versions.

Stay healthy and many thanks in advance.

Hans

Hi Guys,

My "OOM/memory leak/LC file" issue turns out to be far older than I had realized. For that reason and combined with the severity of the evidently well known OOM crashes, I find it rather strange that nobody amongst all the technical FS experts has as yet been able to create some kind of scanning method to root out the OOM causing LC BGLs.

In some older forum posts on the subject, there is some talk about a program named "FSManager",

which evidently included such a scanning function but this seemed to be very unreliable, something which is even confirmed in it's readme file. However, I downloaded the program, along with it's system date changing patch but have as yet not been able to get it working, even although I installed it in it's default C: Windows position.

It's now also become clear (to me) that during the always unnoticed and variable periods before the OOMs actually occur, one of the CPU cores is constantly running (in a loop) at almost full capacity, which negatively influences many other FS functions.

All the more reason for a more reliable scanning process for selectable scenery folders.

Anyone ?

Cheers

Hans