P3D V3 FMC memory leak back?

[PinkPony 171]

Hi Guys,

I switched to P3D V3 a few weeks back and have never been happier.

As usual I have done many OMDB (fly tampa) to KORD/KIAD/SBGR/SBGL (flightbeam/fsdreamteam etc.) flights without any issues (as expected). 

However, 3 hours into a OMDB-KSEA (default) yesterday I OOM'd! I was shocked to say the least, considering it happened a few hours out of OMDB and considering that I had no KSEA add-on scenery it could not have been related to that.

This made me think of the old FMC VAS leak, caused by specific conditions including "heading-to-radial intercept maneuver" as Rob outlined here when discussing the original issue and fix in detail.

 

http://www.avsim.com/topic/468259-07may15-detailed-discussion-of-resolved-777-vas-leak/

 

 

So, let me define it for you again, because I want to make it clear how hard it was to run into this particular problem:

• Prior to departure you had to load an approach with a heading-to-radial-intercept maneuver.
• That heading-to-radial-intercept maneuver had to be in a specific location in the missed approach procedure.  (Presence alone was not enough- it was also related to location of the maneuver...)
• You had to then run the simulation for 4-10 hours before you would begin to notice the effects of the runaway computation or experience an OOM that wasn't related to scenery loading.
• The airplane had to be in motion.

 

 

 

 

This got me thinking that KSEA's missed approach is resulting in this leak once again.

So I loaded up on the ground at KSEA, loaded a KSEA SID and a STAR and observed VAS. No leak/decrease over the course of a hour.

However, as soon as I proceeded to load ILS16L (which of course contains a "heading-to-radial intercept maneuver" in its navdatda code) I began to observe a instant VAS decrease and leak. Logged using FSUIPC's 024C function.

Next, and to confirm the issue, I removed the missed approach code and thus the "heading-to-radial intercept maneuver" from the KSEA SIDSTAR navdata, proceeded to load up on the ground at KSEA again, load a KSEA SID and STAR and this time immediately load ILS16L (no missed approach segment in this case). And have now been sitting for 30 minutes without any decrease in VAS whatsoever.

Looking at Rob's comments from back in May, this seems to be even worse as the problem does present itself on the ground, and also occurs instantly and at a far greater rate than last time! As soon as the missed approach and the "heading-to-radial intercept maneuver" code is loaded!


Now, I came across this thread from a few weeks back, and noticed the airport being discussed was KSFO. Looking at that SIDTSTAR navdata, it also includes as expected a  "heading-to-radial intercept maneuver". Same code in KSFO navdata causing the leak? I think so! http://www.avsim.com/topic/475918-do-i-have-another-memory-leak-caused-by-fmc/

 

 

 

 

 

AIRAC 1511 (current) ILS16L code and missed approach (unchanged, straight from navigraph).

APPROACH ILS16L FIX KARFO AT OR ABOVE 3200 FIX DGLAS 1900 RNW 16L HDG 165 UNTIL 900 TRK 131 INTERCEPT RADIAL 161 TO FIX TEBNE FIX TEBNE AT OR BELOW 2000 FIX MILLT AT OR ABOVE 5000 HOLD AT FIX MILLT RIGHT TURN INBOUNDCOURSE 341 LEGTIME 1

 

This causing the immediately noticeable leak!
 

 

 

However,

Changing it manually to this and under the very same conditions: (note: I removed the missed approach code and  "heading-to-radial intercept maneuver")
 

ILS16L FIX KARFO AT OR ABOVE 3200 FIX DGLAS 1900 RNW 16L

 

 

No leak whatsoever!!!

 

 

 

I have just submitted my findings to PMDG, and I suggest anyone else who can prove this VAS leak do the same! The more information they have from us users, the easier it will be to solve this very frustrating bug.

For now, I will have to make sure that I manually remove any  "heading-to-radial intercept maneuver" missed approach code from SIDSTAR navdata files such as KSEA's.


 

[PinkPony 171]

I am continuing to test the KSEA SIDSTAR navdata file, right now I am trying different combinations of the missed approach in an attempt to find the line of code responsible for causing the leak. 

To summarize:

With AIRAC 1511, KSEA's ILS16L missed approach coding will result in a immediate leakage of VAS. 
Without the missed approach code (by manually removing it from the SIDSTAR navdata (KSEA.txt) there is no VAS leak whatsoever.

If you would like to confirm this, simply set the PMDG777 at any airport in the world (default scenery) clear skies, and set that airport as the origin, (make sure to choose a departure runway) and set KSEA as destination ( and be sure to choose ILS16L as the arrival). Make sure you activate the RTE.

 

Then watch your VAS begin to decrease more and more eventually resulting in a OOM.


 

[PinkPony 171]

400nm to KSEA now 12hours and 30 minutes and VAS has been stable since shortly after leaving flytampa OMDB (increased due to P3D v3 dumping the scenery).

No issues whatsoever as expected, now that I have removed the missed approach coding from KSEAs navdata file.

Does anyone have any idea what part of the missed approach is causing the memory leak?

 

[fnav77 56]

Interesting stuff!

[SuperG 31]

No doubt PMDG have seen this and will check it out.

[pcubine 143]

No doubt PMDG have seen this and will check it out.

 

I believe you assume too much. A ticket to Tech Support with a link to this thread would be better.

[PinkPony 171]

I absolutely agree Michael, many assume that simply posting here is enough to get a potential problem, verified and fixed by support.

 

The whole point of the ticket system is to be able to track potential problems and solve them efficently and effectively, which is of course exactly why I sent in a ticket before I started this thread.

 

Ryan has responded to my ticket and they are investigating. I will do some testing in FSX (good thing I still have it installed) and will report back. From memory, one of my last flights in FSX about two months ago, was OMDB-KSEA-OMDB, and if the problem were present and identical in FSX then, I would definitely have OOMd just like I did a few hours out of OMDB like I did in P3D, and while testing this problem by simply loading the approach on the ground and at other default airports across the P3D v3 world, while watching my VAS decrease at an alarming tate.

 

There may very well be a difference between P3Dv3 and FSX SP2 in that the latter does not suffer from the leak! And this is something PMDG will certainly be looking into.

 

And this once again reminds me of why their products are so incredible. The support received with PMDG on bugs and other issues is far beyond anything I have ever experienced in 10+ years of FS9/FSX and now P3D v3. They value and encourage customer feedback and reporting of bugs/issues.

[CaptKornDog 282]

Give it a try with ILS 25L at KLAX since this was one of the original culprits. As I've previously emphasized in my posts documenting my own testing, you absolutely have to create a control scenario. Deactivate scenery, no weather, no traffic, etc.

[xkoote 57]

I have tried twice to fly LOWW to KSFO, and on both occasions I got an unexpected CTD without any notification. On both occasions I was over Canada, 8 hours into the flight and tried switching to Spot view and poof, Gone... It was only my 3rd flight on v3 so I wasn't sure what the problem was. I was flying to KSFO and had ILS 28L loaded, but 5 hours into the flight VAS was at 1.7 Gb so it was hard to believe that it was an OOM. The trip from KSFO to LOWW went flawlessly, even switching views and recording video on landing. I am glad I have found something to look out for.

 

Xander

[JDWalley 354]

Is there a reason to assume this is a PMDG coding error, as opposed to a bug introduced in the latest release of P3D?

[Fabo 213]

There is little reason to assume it's a P3D bug, the airplane systems are self contained. So either it's a bug showed up in PMDG or in the navdata.

[xkoote 57]

I flew a 14:30 hrs flight today. YSSY-OTHH and I again could switch views, record, et al after 12 to 13 hours of flying. No CTD.

Even stuttered while loading OTHH without a CTD. The flight was even longer the LOWW-KSFO. The only 2 differences were

that it was daytime (which I don't think has anything to do) and I was not flying to KSFO.

 

Xander

[PinkPony 171]

I flew a 14:30 hrs flight today. YSSY-OTHH and I again could switch views, record, et al after 12 to 13 hours of flying. No CTD.

Even stuttered while loading OTHH without a CTD. The flight was even longer the LOWW-KSFO. The only 2 differences were

that it was daytime (which I don't think has anything to do) and I was not flying to KSFO.

 

Xander

 

Without stating what scenery you use on the KSFO flights, and the various other potential variables it is rather difficult to pin-point potential culprits.

 

However, it may be possible that KSFO's navdata code contains the same missed approach code which leads to the rapid VAS leak when loading KSEA's ILS 16L approach.

 

What I can do is send you a modified KSFO navdata file (I will simply remove the missed approach segments) and you can then test it on another long XXXX-KSFO flight. If the missed approach code is at fault, this will solve the problem just like it did for me at KSEA.

 

Removing offending missed approach coding is the only permanent solution until PMDG releases a fix with the next update (they are working on identifying and resolving this issue).

 

Let me know and I would be happy to PM you the modified navdata file for KSFO.

 

 

 

 

[xkoote 57]

Hi Leo,

 

I was posting more to help the OP confirm the difference between SFO and other flights.

I would really like to try out your replacement files though. To give a better situation I used:

 

1. FSDT Vienna to FlightBeam KSFO HD

2. Prepar3d v3 Professional

3. OPUS controlling views only

4. Logitech Wingman open and programmed for PMDG

5. ASN

6. Process Lasso

7. vPilot

8. SimServer app

 

I made three flights and all three had CTD's. On the 3rd flight I saved before I tried switching views. So I could 

recover and finish my flight. On none of the occasions did I verify a spike with Process explorer, but on all flights

the VAS remained below 1.8 Gb even right before switching views.

I have made three other flights now that have a similar open apps setup but did not have SFO as destination and

all three ended uneventfully.

 

Cheers,

 

Xander

[PinkPony 171]

Xander,

I will be sending you a modified KSFO.txt shortly with instructions. It is identical to the default AIRAC1513 one, however I simply removed the missed approach segments for ILS28L and ILS28R. 

I have discovered over the past few days that ILS07R at VHHH also results in a VAS leak. I have spent ten hours testing various combinations of missed approach code without being able to identify what is causing the leak.

What is even more troublesome, is that I used the missed approach code from ILS07L and added it to the ILS07R. The idea being that ILS07L never causes any leaks and ILS07R always does. The only solution so far has been to remove the missed approach code completely for those approaches that result in memory leaks. So naturally, I was expecting the missed approach code for ILS07L to not result in a VAS leak when using it as the missed approach for ILS07R. I was wrong however. The leak is just as bad as it is with the default ILS07R missed approach code.

So, in summary once a VAS leaking approach is identified, the only solution remains to remove that missed approach code.

This is becoming very frustrating and I am growing sick of returning to my computer only to find a OOM has occurred.

 

This is precisely what happened a few days back, on my KLAX-VHHH return. I was shocked that a OOM had taken place, considering I had done countless 14-16 hour flights back to VHHH in the weeks/months prior.

 

So why did it happen on this specific flight back to VHHH? Because I selected ILS07R as the approach while on the ground at KLAX. On every other previous flight to VHHH, ILS07L was the approach selected.

 

I have submitted my findings from the past two days to support by updating my support ticket. Last I heard from Ryan on November 4th, when he mentioned the original ticket for the VAS leak issue was being re-opened again for further investigation. 

I really hope this bug can be solved once and for all....