Jump to content

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

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.


Matthew (SuperG) Rhoden

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.


Michael Cubine
xVxT6x.jpg

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.


Kyle Weber (Private Pilot, ASEL; Flight Test Engineer)
Check out my repaints and downloads, all right here on AVSIM

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


Xander Koote

All round aviation geek

1st Officer Boeing 777

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?


James David Walley

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.


--Peter Fabian 
RTFM.jpg

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


Xander Koote

All round aviation geek

1st Officer Boeing 777

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


Xander Koote

All round aviation geek

1st Officer Boeing 777

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

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  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
  • Donation Goals

    AVSIM's 2020 Fundraising Goal

    Donate to our annual general fundraising goal. This donation keeps our doors open and providing you service 24 x 7 x 365. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. We reset this goal every new year for the following year's goal.


    18%
    $4,710.00 of $25,000.00 Donate Now
×
×
  • Create New...