Jump to content
Sign in to follow this  
Pacifica

Always after the engines start x plane crash to Desktop

Recommended Posts

Hallo,

Unfortunately I can not fly this beautiful machine anymore. Always after the engine starts, X plane ends.
Maybe someone can help me.  
Here is the entry of the log file. G64:1680.568: Memory Allocation Error: Run(gfx): draw_SaabOnDrawGauges3D: not enough memory
G64:1680.586: Memory Allocation Error: Run(gui): TQ_ViewerBody_OnDraw: not enough memory
G64:1680.586: Memory Allocation Error: Run(gui): TQ_ViewerDimmer_OnDraw: not enough memory
G64:1680.586: Memory Allocation Error: Run(gui): toast_Windows_OnDraw: not enough memory
G64:1680.588: Memory Allocation Error: Run(xp): main: not enough memory
G64:1680.588: Memory Allocation Error: Run(xp): Saab_Main: not enough memory

 

Thank you for helping me

best Regards,

Norbert

 

 

 

Edited by Pacifica

Share this post


Link to post
Share on other sites

The logs show that you're running out of memory.  You have a lot of plugins and a lot of custom scenery, which besides using memory are also indicating some errors.  X-PLane cannot run an infinite number of plugins or custom scenery. You need to clean up your system and then try again.

Edited by JGregory

Share this post


Link to post
Share on other sites

I also have this issue.  I also have many plugins, but no other aircraft I have crashes because of too many plugins.  Most work just fine.  This must be an issue with the LES Saab.  It could be an incompatibility with one particular plugin, but I don't know which.  XJet from AirFoilLabs or avitab or FSGRW?  Those are some newer ones.  Another user reports a crash with FSGRW but got no support response.

Edited by cwjohan

Share this post


Link to post
Share on other sites
4 hours ago, cwjohan said:

I also have this issue.  I also have many plugins, but no other aircraft I have crashes because of too many plugins.  Most work just fine.  This must be an issue with the LES Saab.  It could be an incompatibility with one particular plugin, but I don't know which.  XJet from AirFoilLabs or avitab or FSGRW?  Those are some newer ones.  Another user reports a crash with FSGRW but got no support response.

Not necessarily.  Example:  for months, everyone thought it was the Saab's fault that X-Plane was crashing when run with xEnviro, because it wasn't crashing with any other add on.  We thought so, at first, too.  To the point that Jim and Ben went through the Gizmo code and the Saab code to see if anything was amiss. 
Andrej (xEnviro developer) finally decided to look into it, at my urging, and with several other people willing to run some tests,  found it WAS xEnviro at fault.  The problem was found and the crash happened whenever xEnviro would pull weather from the weather server.  It was fixed for their next update.  

Add ons are made to run with vanilla X-Plane.  If a crash happens, we'll look into it, but we can only do so with a log file and with the help of the user by eliminating some plugins and seeing if the problem disappears.  Then we can take it further depending which add on is to blame.

 

Share this post


Link to post
Share on other sites
6 hours ago, cwjohan said:

I also have this issue.  I also have many plugins, but no other aircraft I have crashes because of too many plugins.  Most work just fine.  This must be an issue with the LES Saab.  It could be an incompatibility with one particular plugin, but I don't know which.  XJet from AirFoilLabs or avitab or FSGRW?  Those are some newer ones.  Another user reports a crash with FSGRW but got no support response.

We need your Log.txt and GizmoLog.txt files.  Please post them here.

Share this post


Link to post
Share on other sites

Thanks for the responses Goran and JGregory.  I've experimented with removing and adding back various plugins: xjet, avitab, SilverLining, Real Weather Connector.  Of these, the only critical one seems to be SilverLining (part of SkyMaxx Pro).  If I remove it from plugins folder -- no crash.  If I put it back in the plugins folder -- crash returns.  Disabling SilverLining in plugin admin does not help -- only removing the plugin helps.  Changing the real weather settings to not use FSGRW does not help.

Note that with SilverLining installed in the plugins folder, no other X-Plane aircraft crash -- only the LES Saab 1.5.1.  I realize that does not necessarily mean that it is the LES Saab at fault, especially if other users successfully are using SkyMaxx Pro, but it does strongly indicate that.  Please note that my system has 32GB RAM and 8 GB VRAM, so simply running out of memory not too likely, though the log (now lost) from the very first crash mentioned a memory problem at the very end.

I've attached some log.txt files from each crash except the very first.  Sorry, I don't have any GizmoLog.txt files yet.  I will attach one of those later.

Log_saab340a_ctd_03.txt

Log_saab340a_ctd_04.txt

Log_saab340a_ctd_05.txt

Log_saab340a_ctd_06.txt

Log_saab340a_ctd_01.txt

Log_saab340a_ctd_02.txt

Share this post


Link to post
Share on other sites

This time, I started up X-Plane with the LES Saab 340A with the SilverLining plugin (as in the previous test) but never attached the GPU and never tried to start the engines -- I just let it run all by itself in cold & dark condtion.  Crashed after 15 minutes.  So, it would seem the startup sequence has nothing to do with the crash -- it's just a matter of how long since the aircraft has been loaded.  The logs look pretty much the same as the previous test.

Log_saab340a_ctd_08_ns.txt

GizmoLog_saab340a_ctd_08_ns.txt

Share this post


Link to post
Share on other sites

It's definitely not Silver Lining, because I also have Skymaxx installed and I get no crashes.  I do notice Skunkcrafts updater.  I'm a little cautious about that plugin.  It's caused some random issues with the TBM as well.  Have you tried removing that?

 

Share this post


Link to post
Share on other sites
20 hours ago, cwjohan said:

This time, I started up X-Plane with the LES Saab 340A with the SilverLining plugin (as in the previous test) but never attached the GPU and never tried to start the engines -- I just let it run all by itself in cold & dark condtion.  Crashed after 15 minutes.  So, it would seem the startup sequence has nothing to do with the crash -- it's just a matter of how long since the aircraft has been loaded.  The logs look pretty much the same as the previous test.

Log_saab340a_ctd_08_ns.txt

GizmoLog_saab340a_ctd_08_ns.txt

Besides having a lot of plugins, you have a lot of custom scenery as well.  I would suggest you download the X-Plane demo as a clean install, then install the Saab and test,  Ifr all is OK, add SkyMaxx and test again.  Let us know what you find.  

 

Also, are you running in VR mode ?

Share this post


Link to post
Share on other sites
On 11/10/2019 at 3:41 PM, JGregory said:

Besides having a lot of plugins, you have a lot of custom scenery as well.  I would suggest you download the X-Plane demo as a clean install, then install the Saab and test,  Ifr all is OK, add SkyMaxx and test again.  Let us know what you find.  

 

Also, are you running in VR mode ?

That's a VERY large amount of work for me, but I'll do it in order to narrow down our understanding of where the problem is.  Shouldn't we be looking at stack traces from this very reproducible crash instead?  Keep in mind that none of the many other aircraft I have crash this way.  If the problem really were too many plugins or too much scenery, my other aircraft would crash too.  They don't.

Nope.  Not using VR, though I see some VR messages in the log.txt files.

Here's my educated guess as to the crash cause:  SkyMaxx Pro is leaving in a trashy state some part of memory (e.g., x-plane data refs) that the Saab 340A uses and does not check for validity before using.  Other aircraft, for whatever reason, either don't use this particular memory or check it for validity before using and thus do not crash.  If this theory is correct, the Saab 340A most likely will continue to crash in the above X-Plane demo scenario.  If the Saab 340A crashes when completely idle (cold & dark and on the ground), then that should narrow down quite a bit which X-Plane data refs need to be checked.

 

Share this post


Link to post
Share on other sites
39 minutes ago, cwjohan said:

That's a VERY large amount of work for me, but I'll do it in order to narrow down our understanding of where the problem is.  Shouldn't we be looking at stack traces from this very reproducible crash instead?  Keep in mind that none of the many other aircraft I have crash this way.  If the problem really were too many plugins or too much scenery, my other aircraft would crash too.  They don't.

Nope.  Not using VR, though I see some VR messages in the log.txt files.

Here's my educated guess as to the crash cause:  SkyMaxx Pro is leaving in a trashy state some part of memory (e.g., x-plane data refs) that the Saab 340A uses and does not check for validity before using.  Other aircraft, for whatever reason, either don't use this particular memory or check it for validity before using and thus do not crash.  If this theory is correct, the Saab 340A most likely will continue to crash in the above X-Plane demo scenario.  If the Saab 340A crashes when completely idle (cold & dark and on the ground), then that should narrow down quite a bit which X-Plane data refs need to be checked.

 

The problem is that your log files are not indicating anything with regard to the crash.  Instead of having you remove all your scenery and remove all your plugins, it would be easier to just install the demo and test.  That way we can start with a clean slate and, if it still crashes with SkyMaxx we know exactly where the problem is.   Otherwise there are just too many combinations to debug.    Without that test I don't really have any other suggestions. 

Of course anything is possible, but just reading and writing datarefs should not cause a CTD.  The Saab and SkyMaxx could write to the same dataref and cause erroneous behavior but a CTD is not likely.  I'm not sure exactly what you mean by "validating" a dataref before using it.  You are certainly not the only customer who is using these two products in conjunction with each other, so the problem is not likely as simple as a "clash" between the two. 

 

Share this post


Link to post
Share on other sites
5 hours ago, JGregory said:

The problem is that your log files are not indicating anything with regard to the crash.  Instead of having you remove all your scenery and remove all your plugins, it would be easier to just install the demo and test.  That way we can start with a clean slate and, if it still crashes with SkyMaxx we know exactly where the problem is.   Otherwise there are just too many combinations to debug.    Without that test I don't really have any other suggestions. 

Of course anything is possible, but just reading and writing datarefs should not cause a CTD.  The Saab and SkyMaxx could write to the same dataref and cause erroneous behavior but a CTD is not likely.  I'm not sure exactly what you mean by "validating" a dataref before using it.  You are certainly not the only customer who is using these two products in conjunction with each other, so the problem is not likely as simple as a "clash" between the two. 

 

A typical programming mistake, for example, would be to use the value of a given dataref as the denominator of a division without checking first if it is zero.  A divide by zero can cause a crash in a lot of different kinds of software, depending on if and how errors are trapped and dealt with.

In any case, though, I've created a new stripped down copy of X-Plane based on the demo that now contains only the LES Saab 340A and Sky Max Pro + Real Weather Connector and Western USA scenery, plus the usual default aircraft and default airports.  No custom airports and no orthophoto scenery.  The Saab so far is working OK in this environment.  No crashes.  It's difficult to know if I've set everything up the same.  Until I've used SkyMaxx Pro a bit with FSGRW it may not be the same (e.g., there were no .rwx metar files initially).  I'll keep testing.

Edited by cwjohan

Share this post


Link to post
Share on other sites
5 hours ago, cwjohan said:

A typical programming mistake, for example, would be to use the value of a given dataref as the denominator of a division without checking first if it is zero.  A divide by zero can cause a crash in a lot of different kinds of software, depending on if and how errors are trapped and dealt with.

That's programming 101.  I can assure you that Laminar, LES, and Maxx-XP are all seasoned enough to know to NOT divide by zero and check the value prior to doing the division.

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  

  • Recently Browsing   0 members

    No registered users viewing this page.

×