Version 2.1 OOM and possible memory leak.

[Brian Doney 127]

You can dislike my comments all you want, but I am putting my money where my mouth is.

 

I don't believe in "luck" when it comes to software. Once again, we'll just move the goalposts since that's easier than confronting the actual evidence being presented.

 

Lucky...are you kidding me ?

 

EDIT; I just want to add, I want to see what the issue here is too. This is the most boring thing I've done in months, but I am doing it for a reason. Just handwaving away the fact that I am running max veg and nowhere near an OOM after 2 hours isn't cool. Let's do away with the dislikes and other such and try to figure it out.

 

Or you can return to insisting this issue is something that it quite obviously isn't. That's up to you.

[LHookins 3,103]

 

 

Lucky...are you kidding me ?

 

Napoleon, when presented with a new general, would ask, "Is he lucky?"  I don't know if Napoleon actually believed in luck, but on a battlefield if someone's always in the right place at the right time, he might be considered lucky, although the real reason is that he understood the principles of war better than the average general.

 

"Lucky" is a tricky thing to pin down, but I'd say you were as lucky as those generals Napoleon was talking about.

 

Hook

[Brian Doney 127]

Well, I apologize for letting a bit of my frustration show, but this is exactly what I alluded to earlier, and is also what happened last time I did extended tests of P3D.

 

It's never enough to just show something can be done. There are always 100 caveats, and the more conclusive your evidence, the more hand-waving occurs. 

 

I'll consider this test concluded from my point of view. If someone comes up with a better scenario, I'm open to it. I'd like to talk with Jim more to compare notes, as I do believe he is the only other person testing bone stock.

[n4gix 4,947]

So Fr.Bill. Is at all possible for any of theses errors to cause a memory leak or excessive VAs usage?

No, errors in an XML "gauge script" will simply not be completely evaluated. They will work up to the error and then simply skip over the rest.

 

However, that's not to say that poorly coded XML even when supposedly operating normally cannot cause problems. The same applies to C and C++ compiled gauges.

 

The way to test if any particular aircraft's gauges are causing problems would be to simply substitute an essentially blank panel.cfg temporarily...

[Brian Doney 127]

No, errors in an XML "gauge script" will simply not be completely evaluated. They will work up to the error and then simply skip over the rest.

 

However, that's not to say that poorly coded XML even when supposedly operating normally cannot cause problems. The same applies to C and C++ compiled gauges.

 

The way to test if any particular aircraft's gauges are causing problems would be to simply substitute an essentially blank panel.cfg temporarily...

 

What about a situation where you have dependencies between XML gauges ? 

 

A situation where one bit is waiting for the other bit to write but it never does as it doesn't parse ?

 

Am I talking out of my nether regions again ?

[Jim Young 2,356]

 

 

Taken just now.
This isn't a leak. This is people running incompatible addons, or a combination of settings that have been warned against from the start.

 

 

Yes, brian is lucky, it doesn't affect him, truth be told, it doesn't affect me if I'm willing to live with a 3nm or so circle of tree coverage (which I am, till LM fix it, but I do want them to fix it, and soon)

 

Napoleon, when presented with a new general, would ask, "Is he lucky?" I don't know if Napoleon actually believed in luck, but on a battlefield if someone's always in the right place at the right time, he might be considered lucky, although the real reason is that he understood the principles of war better than the average general.

 

I'm sorry but you all are not reading and counting correctly.  Brian had much less VAS than I had and the FSUIPC program was going ballistic with it's dinging (post 82).  I started out with over 2 GB's of VAS.  Brian's gauge does not even hardly register any VAS left.  The first gauge reading:

742588 KB = 0.708GB

2nd gauge reading:

739264 KB - 0.705 GB or 722 MB's

3rd gauge reading:

682960 KB = 0.651 or 667 MB's

and the last one (going over the lake):

866976 KB = 0.827 GB or 847 MB's (yes he got more VAS here but still in dangerous territory for an OOM.  When it gets down to the 430000 KB area, then he should be hearing the dings from FSUIPC.  Don't know when Bob's beeps or dings go off.  I would expect the same).

I used the following link to look up the number of KB's - http://www.whatsabyte.com/P1/byteconverter.htm.

 

Less than 1GB of total VAS is okay?  Out of 4GB's of virtual address space?  So Brian has proven there is a problem too.  Like I said, I started off with over 2GB's of VAS when I first started up P3D but it depleted fast. 

 

I'm finished here as I have done my job of proving the loss of VAS with the vegetation slider even up to the normal level.

 

Best regards,

[Brian Doney 127]

Well that's really a shame.

 

I agree, that less than 1 GB of VAS is low, and that's why I don't run Extremely Dense, or if I did, I would follow LM's advice and keep LOD radius in check.

 

I guess you are correct, you have proven that higher settings result in lower available VAS, but the point is, it will stabilize, which I have proven.

 

The headshot is in post #133, where a properly working system returned VAS as I flew out over the water and left the autogen behind.

 

If LM has made any mistake, it is in allowing for such high autogen and LOD settings to be use simultaneously.

 

I'm sorry if I frustrated you, and I hope you realize my comments made in frustration were absolutely not directed at you. I'd hoped we could look further since I do trust you are running a stock sim. I hope you will reconsider.

[n4gix 4,947]

What about a situation where you have dependencies between XML gauges ? 

 

A situation where one bit is waiting for the other bit to write but it never does as it doesn't parse ?

XML scripts are not as "dependent" as C gauges are. If any one gauge is waiting on something from another, they will simply skip along and ignore the absent value without causing any issues at all. Edited February 17, 2014 by n4gix
Added "not" to a phrase

[Jim Young 2,356]

 

 

If LM has made any mistake, it is in allowing for such high autogen and LOD settings to be use simultaneously.

 

Well, as I recorded above in post 131, I checked to see if lowering the settings would help.  They didn't. I still struggled for VAS.

 

Best regards,

[Brian Doney 127]

Well, as I recorded above in post 131, I checked to see if lowering the settings would help.  They didn't. I still struggled for VAS.

 

Best regards,

 

I'm not positive if this would be related, but LM have also mentioned that a reload is often required after making changes in the menus. Not really sure, and I don't claim that this is definitely the case here.

 

If we look at the differences, I did fly the Beech, you were in the Raptor. It might be that the speed factor comes into play there, but that somewhat supports the idea behind having different graphics profiles for different types of flying.

 

LM did not go into this much detail, but my impression from what they have said, is that it is entirely possible to overload the engine using sliders and default scenery alone, and that it is up to us to work to find balance between LOD radius and autogen density for the type of flying we will do. It may very well be that with an advanced addon aircraft, Extremely Dense might always be 100% off limits. That's not really a surprise to me, as the number of objects is really quite over the top over such a large area, in my opinion.

 

If someone wants to disregard LM's advice and use high LOD and autogen settings together, well, in that case I think that the only thing that might need fixing are the options made available to us. 

 

For full disclosure, I flew that test at an LOD of 4.5. Had I run 6.5 I have no doubt I would have had an OOM, but, I wouldn't do that, since I have already been warned not to. Were I to have been in an advanced addon aircraft, I likely would have had an OOM as well. I think the difference of opinion we are having is, that this makes perfect sense to me, and is simply a compromise that must be made as long as we are working with 32bit.

 

I hope if nothing else, that I have at least shown that there is likely not a leak. 

 

I guess, in the end, that was my point from the beginning. If your addon a/c is incompatible or chews up 1GB of VAS all by itself, or if you are running settings above what has been recommended ( or all of the above, as I feel is likely in most of these reports ), how can the resulting OOM be considered a bug ? Or even a surprise ? 

[mganz121 159]

So now we have to worry about frame chasers and slider chasers ????  :lol:  :lol:  :lol:

[peppy197 165]

To compensate for the lack of trees (which I rarely see anyways) a setting of sparse allows me to complete most flights

 

AND set 12 layers in AS2012 which makes for some nice clouds at least (IMO)

Just did a KJFK to CYHZ with FsDreanTeam KJFK and Simaddons CYHZ and FTX_Vector with AS2012 at 12 layers in REX4_1024 clouds

 

Never a burp and landed the AXE at CYHZ in zero viz  (snow storm)

 

All for the want of trees... could not see any anyways with that snow falling....

 

2.5G RAM usage at departure, 2.7 G upon approach

 

 

Allen

[Jim Young 2,356]

No, we still have to worry about VAS.  That's what is being depleted for some reason and fairly fast.  I was going to mention earlier though that back when FSX/FS9 were first released, everyone was looking at the FPS counter.  Now we have tools to be constantly monitoring the amount of VAS thanks to COL (Ret) Bob Scott and Pete, the developer of FSUIPC.

 

Best regards,

[Jim Young 2,356]

 

 

For full disclosure, I flew that test at an LOD of 4.5. Had I run 6.5 I have no doubt I would have had an OOM, but, I wouldn't do that, since I have already been warned not to. Were I to have been in an advanced addon aircraft, I likely would have had an OOM as well. I think the difference of opinion we are having is, that this makes perfect sense to me, and is simply a compromise that must be made as long as we are working with 32bit.

 

Good info Brian but I posted above that I did lower my LOD_Radius to normal (not sure what the LOD would be) and reduced the Texture_Max_Load to 1024.  It was slower in degrading VAS but by the time I had reached Washington, it was in the 430000 which is about where the FSUIPC module starts warning of an OOM.

 

Best regards,

[Brian Doney 127]

Good info Brian but I posted above that I did lower my LOD_Radius to normal (not sure what the LOD would be) and reduced the Texture_Max_Load to 1024.  It was slower in degrading VAS but by the time I had reached Washington, it was in the 430000 which is about where the FSUIPC module starts warning of an OOM.

 

Best regards,

 

Well, maybe it is the Raptor then, I don't know.

 

It's getting a bit late tonight, so I will try it tomorrow if I have some time. I feel that it doesn't really matter though, as at such high settings, I'd expect to be on the edge. If you eventually settled at 100 MB free, but it did eventually settle, then that still isn't a leak, just a sign that settings will need to be compromised.

 

The fix ? Lower the slider 

 

I was just messing around again, and the number of objects is staggering at full right sliders. I'd only briefly tried it there right after release of 2.0, and only to slew around a bit. This was the first time that I'd actually tried flying with it set so high. I guess I just don't understand why this is such a mystery. 

 

LM have given us the options to fully break the engine if we adjust these options carelessly. 

 

YAY A CAR ANALOGY !

 

It's like LM brought us a restored Charger, that they'd added some shiny bits too, with the clear instructions that we could do one of two things*:

 

1) Go fast.

 

2) Turn corners.

 

...but never both at the same time.

 

From my perspective, half of the sim community have gone careening off the road at the first bend, and are trying to blame the car !  :lol:

 

Anyway, have a good night, I'll try to break it some more tomorrow. 

 

 

*not unlike most American cars  :lol: