Version 2.1 OOM and possible memory leak.

[RWFeldman 159]

“The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge.”
― Stephen Hawking

[Brian Doney 127]

:rolleyes:

 

A person who's only contribution to this thread has been their "gut feelings", now quoting Stephen Hawking.

 

That is rich  :lol:

[ChaoticBeauty 6,692]

Some really good info:

 

Then I guess the only way to prevent OOMs is to go 64-bit. Though that still doesn't explain why some users who fly slow are still getting OOMs. It would be nice if he explained what speed in knots is the troubled area.

 

Another solution would be to move autogen entirely to the GPU, which would take the load off the main RAM and put it on the VRAM (and VRAM has started to get very large lately). This would break compatibility with all scenery add-ons, but so would 64-bit.

[Brian Doney 127]

Then I guess the only way to prevent OOMs is to go 64-bit. Though that still doesn't explain why some users who fly slow are still getting OOMs. It would be nice if he explained what speed in knots is the troubled area.

 

Another solution would be to move autogen entirely to the GPU, which would take the load off the main RAM and put it on the VRAM (and VRAM has started to get very large lately). This would break compatibility with all scenery add-ons, but so would 64-bit.

 

If I had any aircraft left to fly in P3Dv2, I'd likely revert to legacy autogen via the .cfg setting for now, and run sparse.

 

Unfortunately it's too much of a crapshoot on whether or not the aircraft itself will also cause an OOM for me to bother. This may somewhat explain why, as you say, some were still seeing OOMs while flying slow, and I wasn't. It may have simply come down to the aircraft. The BE58 seems to be pretty well behaved, in contrast to the Raptor, which in addition to speed, seems to have some XML troubles going on as well.

 

As far as moving it all over to the GPU, I won't speak to the technical hurdles there, but VRAM exhaustion is nearly as bad as system RAM exhaustion, in that once the limit is reached, you may not OOM, but performance will absolutely fall off a cliff. 

 

If only they were willing to open up the beta process a bit...

 

EDIT: More info:

 

The out of memory issues that most people are seeing seem to be strongly correlated with the paging issues. Flying faster than the scenery can load is a leading cause of memory issues. Setting an affinity mask which is negatively affecting paging performance could indeed increase the frequency and severity of memory issues. P3D will usually generate a pretty good affinity mask, but feel free to experiment to find the best settings for your machine.

 

Zach Heylmun

Software Engineer - Prepar3D® Team

 

[JimmiG 244]

If your flying slow enough to have tiles load in but to too fast for paging to keep up, then some tiles don't get unloaded properly. This is why some users can fly for hours without OOMs and see VAS go up and down while others see it go up and up before an OOM.

 

 

I think this is what's happening to me. I've been doing most of my testing with the stock Mooney and Bonanza which are certainly faster than a Cub or C172, but nowhere near as fast as the F22. I can see that the terrain engine is keeping up, but just barely. I sometimes get the occasional blurry tile or unloaded autogen, but it tends to clear up before it becomes a problem.

 

Another thing is that I've seen OOM's with as much as 1.3 GB of *available* VAS, which seems to suggest some kind of memory fragmentation due to this memory leak. With P3D 1.4, I would finish flights with as little as 250 - 300 MB of available VAS but it was never a problem.

 

Looks like LM are working towards identifying all the memory problems and tightening things up, though. Hopefully a hotfix or minor release will fix these problems.

 

On a lighter note, I've been slewing (yes, slewing) all over FTX NorCal in P3D 1.4 for *hours* without any OOM's or other crashes. The terrain fills in amazingly quickly (within seconds after stopping) and everything is super-smooth. It seems with FS and now with P3D, a new version always comes out just at the moment when the previous version has reached perfection.

[Brian Doney 127]

I hope no one minds if I continue to add relevant quotes here as I find them, as they are rather scattered throughout the LM forum.

 

Latest info here:

 

Background jobs hold a reference to the tile they work on which prevents it from being deleted while the job is active. Thread contention can make jobs take much longer to finish which keeps the scenery data for that tile from being released. Paging performance would impact memory usage with or without any leaks. There does appear to be a leak of sorts where some tiles don't get released, but it only happens when paging performance gets in a bad state. We do plan on detecting OOMs and putting safeguards in place to prevent crashes but if a user loads up 6GB of scenery content and a 2GB user aircraft add-on, we can't magically decide what content and settings should be disabled/reduced. In a case like that, what you'll likely get is a warning and a chance to save your flight or change your settings

 

Beau Hollis

Rendering System Lead - Prepar3D® Team

 

 

So it would actually seem, from reading this, that if you can find an aircraft that works, and if you can manage to run reasonable settings, and finally if you haven't applied bad tweaks that get in the way of things, well then you might just be able to manage until the next patch.

 

Unfortunately, the first "if" is the tough one.

[Guest]

Lionhearts Creations posted this on their Facebook page:

 

It looks like Prepar3d will not be looking at a update soon for crashed gauges. This just posted from Beau at Prepar3d:

 

Start quote LM

Models missions and gauges all use the same scrip evaluator. We added some script validation code to help with scripted actions in mission creation, but it appears that the error messages are being logged internally even when content error reporting and gauge debugging options are not enabled in the cfg. There may have been one or two new checks added as well, but we haven't gone through it with a fine tooth comb just yet. If the xml validates, but some scripts have errors, the system can get in a state where the same error string is created and logged over and over again eventually leading to OOMs. I would suggest turning on gauge debugging in the Prepar3D.cfg and either fix the errors or avoid using any content that pop up alerts until the next patch. We're sorry about the legacy content effected by this. A silver lining may be that add-on developers might be motivated to go back and clean up scrip errors.

 

Beau Hollis

Rendering System Lead - Prepar3D® Team 

End Quote LM

 

It looks like all planes and GPS systems will need to be modified to run with the new 2.1. Lionheart Creations cannot rebuild all the aircraft in a short amount of time, so we cannot support 2.1. As we can, we will begin modifying our planes to work with the new coding. I do not know if all the planes will be able to be converted. This is most unfortunate.

 

Bill

LHC

 

So this seems to be the biggest cause of OOMs in 2.1. And it even made at least one developer stop supporting P3D 2.1 for now…! 

 

Does anyone know if default planes are also affected by this? I usually fly the A2A C172 but maybe I should use a default plane for now. Would be VERY odd (and a bad thing) if even default planes have this problem imho.

 

Some more quotes that give some more insight:

 

The issue is with the XML Parser in V2.1. It has discluded certain XML symbols, such as > so that code strings or scripts become inoperative. Its the sim. I can only wonder how long it will take to get a fix. Another 2 months? One gentleman has 900 issues in his GPS alone, one gauge, in order to get it working for V2.1. 900 is quite a few edits to get the gauge to work. Imagine a fleet of planes and various gauges.

 

And:

 

They have tightened the code, deleted use of certain symbols, and this will also effect models as they have imbedded code in them. Not warning us, I think was a bit wrong. There are A LOT of planes out there that would suddenly have to be redone, not just mine, but many many many more. 

Some people are already repairing code (changing it) and getting things working. I want to hear from LM what they intend to do before I start ripping models apart and redoing code and redoing all of my MFD codes.

 

Presently, we are not supporting 2.1. If things change, I'll post it. For now, we are just to swamped with work to start rebuilding the codes on all of the existing fleet.

[Brian Doney 127]

Yeah it's really not a good situation, no matter how you look at it.

 

From purely an end user perspective, what about all of the FSX aircraft that aren't being actively maintained ? I'd say the majority of FSX aircraft available are in the grey area regarding P3Dv2, where they weren't actually supported, but weren't prohibited either. In 2.0 they mostly worked well enough, but now, many won't work at all or with severe side effects. A2A are a great example, will there now be no A2A for P3Dv2, in any form ?

 

Will all of this extra work, surely many devs will end up having no choice but to charge a fee for upgrades, which in and of itself is perfectly reasonable. Nothing is truly free after all, and time spent working on this, is time that could have also been spent working on something that pays the bills. Might not be too big of a deal for everyone, but look at what Lionheart has had to do.

 

The thing is, I'm not sure I'm willing to purchase a new fleet now, and then again for 64 bit. Or 2.2 when they add another surprise.   :unsure:

 

I don't know, I guess I'm rambling a bit, and I don't really have any evidence that it will be as bad as all of that, but, this one little change sure did take the wind out of the sails for me. I can only imagine if I actually ran a business that was impacted.

[Guest]

I am also amazed that LM didn't warn the developers about this AND that this apparently wasn't noticed during beta testing of the patch. LM seemed to pay much attention to backward compatibility or at least they said it was important, but now they broke compatibility with a lot, if not all, add-on planes…? Very odd. 

[Novation 534]

Well, despite having a very nice time with P3Dv2 over the past couple of months, for the time being I'm going back to FSX (and I can't believe I saying this) to have some untroubled flying time. Since updating to 2.1 my troubles seem to be mounting, to the point where I can't use the sim; I bought the wonderful FTX NCA but in v2.1 it may OOM at any point, be that after one minute or one hour, though often sooner rather than later., and this is a first for me... I don't fly fast and hard, I have turned my settings down, I avoid switching views too much, but still the sim [or the sim with certain add-ons] feels unstable.

 

The flashing blocks of trees in some areas of forest is also driving me nuts, as are some of the other niggles like the spinning clouds and AA. For the moment I just want to enjoy FTX NCA and all my other scenery without the worry that any second the sim will stop [i have no interest in flying 'default']... I've never had an OOM in FSX no matter what I do and I have now resorted to looking for 'magic bullet' tweaks and fixes, and there lays the path to madness :crazy:

 

I will miss the volumetric fog, and some of the other effects, but at the moment they are not worth the downsides... I will be jumping on any updates that fix the issues within a heartbeat as I do want to return to this platform [i want to use what I've paid for after all]

 

I'm sure some will hit the 'dislike' button for committing the crime of going back from P3D to FSX but right now I don't care I just want to fly :good:

[Guest]

I'm sure some will hit the 'dislike' button for committing the crime of going back from P3D to FSX but right now I don't care I just want to fly

 

 

 

Well, actually, going back to FSX for now also crossed my mind… but I am afraid the popping up autogen will be even worse to me than it was before I used P3D v2. But I am very close to giving it a try, I have to say! If not to actually use it, then to see why I was loving P3D v2 so much…  ^_^

[NikkiA 7]

Well, actually, going back to FSX for now also crossed my mind… but I am afraid the popping up autogen will be even worse to me than it was before I used P3D v2. But I am very close to giving it a try, I have to say! If not to actually use it, then to see why I was loving P3D v2 so much…  ^_^

 

After being frustrated with 2.1 I was suprised when I went back to FSX and noticed that the autogen'ed trees stretched out far further than I remembered, the only thing I can think of is that with 2.0 I'd set my slider to 'dense' and between having to dial that back to 'normal' and the change to the autogen radius in 2.1 that it's brought it back so far that FSX looks like 'forever away' in comparison.

 

Of course the real problem with FSX's autogen has always been the buildings, time will tell if I can get used to a reduced radius of that again.

[Novation 534]

Well, actually, going back to FSX for now also crossed my mind… but I am afraid the popping up autogen will be even worse to me than it was before I used P3D v2. But I am very close to giving it a try, I have to say! If not to actually use it, then to see why I was loving P3D v2 so much…  ^_^

 

Well, its there and you can't get away from it, but I think its a price worth paying at this point. I tend to fly [very] low and slow, so it not a major issue for me. Doing a couple of hours flying over FTX NCA in FSX last night was a pure joy and I really did not notice the popping that much... far less than the flashing blocks of trees in P3D. With the OOM's I ended up with far less agn than I have in FSX as I had to keep turning things down... all in vain.

[LHookins 3,102]

I doubt LM can leave the parser in its current condition.  "Oh, all you have to do is go back and clean up all your code..."  EXCUSE ME!?  Some of these guys are no longer alive.  Others have moved away from the hobby and cannot be contacted.  Some no longer have the code, as it existed two machines ago.  Some just don't want to mess with it, and who can blame them?  For some, it's way too much work when they've got current projects to finish.

 

This has the potential to affect every aircraft ever created that uses any form of XML in either a gauge file or the model file.  At least we can fix the gauge file problems ourselves, but the compiled model file XML is beyond our reach, and apparently it doesn't even throw an error.

 

900 issues in a GPS?  Somehow, I believe it.

 

I just don't think LM can leave the parser in this condition.  Just wait and see how they fix it, because it won't work the way it is.

 

Hook

[spirit_66 2]

Things are never as bad as they seem.

Spirit