Sign in to follow this  
calzonister

P3D V3 FMC memory leak back?

Recommended Posts

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.


 

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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.


 

  • Upvote 1

Share this post


Link to post
Share on other sites

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?

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Upvote 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

 

 

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

  • Upvote 1

Share this post


Link to post
Share on other sites

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

 

Let me preface this by saying this is all in FSX. It is really aggravating. I was involved in the testing for the original VAS leakage in FSX. I conducted quite a few  long flights between EDDP-KLAX that were without weather, traffic,  no time acceleration, and default scenery so that other testers could reproduce the flight and see what the results were. A patch was released and the problem was solved until I flew to VHHH. I just caught the OOM at 3.9GB, saved the flight, reloaded the saved flight and finished it. Now I don't enter the STAR or runway until I am about an hour from VHHH. Not a satisfactory solution because I can't get an accurate ETA because the last three or four waypoint on the core route have no altitudes until the STAR and runway are entered. The problem I see here is 07R/25L is not a landing runway. Landings are done on 07L/25R. Have you tried 25R and if you have do you get a VAS leakage or is only on 07L?

 

Additionally, EDDP has VAS leakage when a STAR is used for 26R, If a transition is used it is okay. LUKOP 2W is an OOM. LUKOP 26 is okay. Since I was using Process Explore to monitor the VAS used I was able to catch this and save the flight. I use EDDP a lot for KLAX-EDDP and VHHH-EDDP. At least twice a week. Needless to say all landings on 26R use a transition not a STAR.

 

I have no problem at KSFO with any runway or STAR causing an OOM but I only fly the NGX into KSFO. What's tell me. It's the T7.

 

The VAS leakage problem still exists.

Share this post


Link to post
Share on other sites

Hi Michael,

I am "glad" to hear that I am not the only one dealing with this extremely frustrating issue. It is the same in both P3D V3 and FSX.

Regarding VHHH, 07L is never a issue. 25R does leak and thus you must remove the missed approach segment from the navdata or select it very late into the flight. I prefer option the former. 

07R is actually a very common arrival runway in the early morning hours at VHHH, and anytime 07L/25R is closed for scheduled maintenance. Furthermore Hong Kong ATC will try to accomodate arriving freighters and bizjets on 07R/25L whenever possible as to minimize their taxi. I only discovered the leak for 07R after I attempted KLAX-VHHH and for the first time my VHHH crashed. All previous arrivals had been on 07L.

ILS16L at KSEA is also a guaranteed OOM.

Can you please also submit a ticket again? Rob mentioned when discussing the previous leak that they monitor these threads for potential issues but ultimately people need to be reporting potential issues. 

Can you confirm 100% any specific approaches where the leak was taking place that were fixed with the last update? VHHH 25R was a problem them, and it continues to be!







 

Share this post


Link to post
Share on other sites

Can you please also submit a ticket again?

 

 
Unfortunately, EDDP-VHHH did not result in an OOM. SIERA 7A and ILS 07R were entered in the FMC before takeoff from EDDF. VAS used was 2.4GB at takeoff, 2.3GB during the flight and 2.4GB on final to 07R. I have eight other VAS usages figure during the flight but they were all close to 2.3GB. The flight was setup with no weather, no traffic, no time acceleration, FSX default EDDF airport and VHHH airport and took 11:01 hours.

Share this post


Link to post
Share on other sites

Disclaimer: I don't own P3D (any version).  I only use FSX SP2.  (I do own FSX SE but never installed it.)

 

I've shot several approaches the past few months into the troublesome runways that I previously identified as "leaky" on my system.  Haven't had an OOM in the 777 yet since the patch that fixed this a few months back.  (Come to think of it, think I only had 1 OOM recently because I rapidly switched between different aircraft models - they just rarely happen on my system.)  But, I suppose that doesn't mean something has changed recently.  I'll do some data logging when I get a chance this week maybe, probably into KLAX ILS 25L.

Share this post


Link to post
Share on other sites

probably into KLAX ILS 25L.

No problems with that runway. I use it at least once a week with the 777F on VHHH-KLAX and EDDP-KLAX. Don't waste your time.

 

Now that I think about, I don't believe I have had an actual OOM at VHHH or EDDP. Right after the VAS fix I still monitoring VAS usage. In those two cases in which the airports were payware, I think I looked at how much VAS was left and decided there was no way in hell I could make it. So I saved the flight and used the saved flight to complete the trip. In both cases it would have been an OOM or a close run thing. Now I will never know.

Share this post


Link to post
Share on other sites

No problems with that runway. I use it at least once a week with the 777F on VHHH-KLAX and EDDP-KLAX. Don't waste your time.

 

Now that I think about, I don't believe I have had an actual OOM at VHHH or EDDP. Right after the VAS fix I still monitoring VAS usage. In those two cases in which the airports were payware, I think I looked at how much VAS was left and decided there was no way in hell I could make it. So I saved the flight and used the saved flight to complete the trip. In both cases it would have been an OOM or a close run thing. Now I will never know.

 

 

Disclaimer: I don't own P3D (any version).  I only use FSX SP2.  (I do own FSX SE but never installed it.)

 

I've shot several approaches the past few months into the troublesome runways that I previously identified as "leaky" on my system.  Haven't had an OOM in the 777 yet since the patch that fixed this a few months back.  (Come to think of it, think I only had 1 OOM recently because I rapidly switched between different aircraft models - they just rarely happen on my system.)  But, I suppose that doesn't mean something has changed recently.  I'll do some data logging when I get a chance this week maybe, probably into KLAX ILS 25L.

In this case I may be looking at a P3D V3 only leak?

 

Would you mind loading up KSEA ILS16L while sitting on the ground anywhere else and observing VAS?

 

In P3D activating this approach will most definitely result in a OOM, and upon Ryan asking me if I had tested this in FSX, I decided to try this approach in FSX and my observation were the same.

 

As of now ILS07R, ILS25R at VHHH and ILS16L are guaranteed OOM's when selected and activated on the ground from anywhere. The VAS leaks at ~100-150Mb per hour in P3D. 

 

 

 

Share this post


Link to post
Share on other sites

Would you mind loading up KSEA ILS16L while sitting on the ground anywhere else and observing VAS?

Is this the default airport or Tax2Gate KSEA. I don't think it would make a difference unless I was going to land there.

Share this post


Link to post
Share on other sites

Is this the default airport or Tax2Gate KSEA. I don't think it would make a difference unless I was going to land there.

Default. And yes, sitting on the ground halfway across the world should will make no difference. I have been using default LPMA RWY05 as my testing ground. Just select a departure, the arrival and activate. No need to start engines or anything. 

 

Much appreciated! 

Share this post


Link to post
Share on other sites

For what it's worth, yes, I tried the 77L KSEA ILS16L loaded up (sitting on the runway at JFK with my computer running overnight).  I did have an OOM with FSX SP2.  I had Taxi2Gate KSEA activated.  I'll have to do some more exploring with other airports/sceneries deactivated.  Unfortunately, busy week or two for me with the holidays so probably won't be able to do that much data gathering and reduction.

Share this post


Link to post
Share on other sites

Default.

Default FSX, no add-ons. Straight out of the box and onto the computer. Route was 26L EDDF to ILS 16L KSEA. VAS used started at 2343KB right after route was executed. At the end of hour 1 it was 2505, hour 2 2611, hour 3 2622, hour 4 2625, hour 5 2614, hour 6 2589, hour 7 2592. I stopped after 7 hours when I saw there was no discernible VAS leak.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this