cwjohan

Another experiment. From my full setup, I removed: 12 airports AutoGate AviTab Little Xpconnect SAM ToLissData ToLissFlightPlans ToLissTerrainData Xchecklist xjet XPUIPC NavigraphSimlink_64.xpl Previously, I had removed: 124thATC64 DataRefEditor EZPushback FlyWithLua core edition HeadShake librain SkunkCraftsUpdater TerrainRadar XFMC xreloaded XSquawkBox Plugins remaining in the plugins folder: Gizmo64.plugin PluginAdmin RealWeatherConnector SilverLining XPLM.framework XPWidgets.framework Result: Started up X-Plane and loaded the Saab 340A at CYLW airport and let it run cold & dark with no further action. After 12 minutes, I got a CTD. Log.txt

Thanks for the input, Ben. Very informative. Pretty esoteric stuff, especially with the use of offset addresses that have to be in the first 2 GB of address space! Someone probably thought no one ever would need more than 2 GB for this type of memory pool, and they thought they were being very clever by using just 32-bit addresses to save space in the memory pool block chains. Is it possible that, in my case with the Saab 340A, the Garbage Collector is running out of memory because the instrument panel drawing code is doing nothing to de-reference some objects no longer needed (e.g., re-creating them on each drawing cycle and never setting to null the reference pointers to the old ones)? The code might get away with it when memory usage is not under stress, but fail when it is stressed? Looking forward to your coming update of Gizmo to provide more diagnostic info.

Here's an example of the Saab 340A loaded in PGUM Guam and just left to run in cold and dark state. There is no ortho within thousands of miles of this place. My only action was to click on the X-Aviation licensing window to close it. After about 17 minutes, it hung. Three log messages indicate an out of memory situation. The Task Manager never showed RAM or VRAM exceeding about 30%. I have 32 GB of RAM and 8 GB of VRAM. G64: 611.008: Memory Allocation Error: Run(gfx): draw_SaabOnDrawBeforeGauges3D: not enough memory G64: 611.008: Memory Allocation Error: Run(gfx): draw_SAAB_PLII_COM1_Panel: not enough memory G64: 611.008: Memory Allocation Error: Run(gfx): draw_SAAB_PLII_COM2_Panel: not enough memory Log.txt GizmoLog.txt

Here are the basic facts and how I see the problem based on more than 40 years software development experience (at EA, among others): 1.) The Saab 340A is one of my favorites but is the ONLY aircraft with which I experience the CTD in question. This tells me that somehow the Saab 340A does something that results in a crash (not necessarily anything wrong). And it tells me that the Saab 340A does something that none of my other aircraft do. We have to ask "What is that something?" 2.) With the basic install of X-Plane and no ortho and no custom scenery, I can have any plugins as I like -- none of them by itself or in combination with others brings down the Saab 340A. This tells me that the CTD is not entirely the fault of any plugin nor is it entirely the fault of the Saab 340A. 3.) The CTD only happens with my FULL X-Plane setup with a large amount of aircraft, scenery, ortho, and an extensive set of plugins. This tells me that the problem likely is memory related. X-Plane is memory constrained when fully loaded like my full setup. Each aircraft, item of scenery, and plugin uses some additional memory just by being present in the configuration, even if it is not directly being used. Loaded ortho tiles also take up additional memory. A few memory error messages in the logs confirm memory usage likely is part of the problem. 4.) The CTD reliably happens without doing anything with the Saab 340A. With my full setup, I can load it cold & dark at PGUM in Guam, where there is no ortho within thousands of miles, and just leave X-Plane running and take no further action and within 12 to 15 minutes it will crash. This is typical of a memory problem. 5.) I have 32 GB of RAM and the Task Manager doesn't show anywhere near all the memory used up before the crash and doesn't show memory gradually being used up more and more the longer X-Plane runs. This indicates that the problem is not a typical memory leak of the sort caused by not freeing up some frequent memory allocation. CONCLUSIONS: 1.) I see no evidence that any plugin is doing anything wrong other than using up some valuable memory space, pushing X-Plane or one of its drivers ever closer to running up against some limitation (a memory pool size?). 2.) I see no evidence that the Saab 340A has an ordinary memory leak. However, it (or possibly Gizmo) does something after 12 to 15 minutes that results in a crash and it something contingent only on the elapsed time -- the user need do nothing specific to cause the crash. That "something" likely is grabbing a big chunk of memory and it likely is a bigger chunk than any of my other aircraft ever grab. The fact that some part of X-Plane or the Saab 340A runs out of memory after a relatively constant amount of time suggests that the alleged memory grab is driven by a timer or possibly some sort of countdown. 3.) I can conclude that no plugin is responsible for this alleged memory grab since, when starting up or flying a different aircraft, I never experience the CTD. If a plugin were responsible, we would see the crash with one or more other aircraft, but we don't. 4.) I suspect that removing SilverLining helps only because it uses a lot more memory than most other plugins (speculation on my part), not because SilverLining has any particular fault. I feel that experimenting with adding and removing various plugins is just a game of "wack a mole" since the critical issue is how much memory is being used, not some fault with any particular plugin. 5.) It is not likely that the Saab 340A simply requires more memory than any of my other aircraft. I have several others that are big and quite complex (A319, A330, B777, TBM 900). So, if there's no timer-driven process in the Saab 340A that grabs a very big chunk of memory around 12 to 15 minutes after the aircraft has loaded, I don't know what to think. Possibly, one of the plugins does that and the Saab 340A is just really big? If you see a flaw in my reasoning, please point it out. There could be some possibility I'm overlooking -- but what? Cheers, Craig

I removed SilverLining from the plugins folder and added xjet back to the plugins folder -- resulted in no CTD -- flight from Yakima to Spokane went fine. Log.txt GizmoLog.txt

I removed the xjet plugin to a plugins_disabled folder and added SiverLining back to the plugins folder -- resulted in a CTD at about the same place in the startup sequence. Log.txt shows out of memory error in last few lines. Log.txt GizmoLog.txt

UPDATE: I started getting crashes again with the Saab 340A. Happens at end of startup sequence as mentioned above. I removed Skunkcrafts Updater -- still got crashes twice. Then, also removed SilverLining -- no crash -- successfully flew from Yakima to Spokane. Flying in eastern Washington State with Orbx Washington with US Washington SD scenery (big), but with only default airports in the vicinity. The log.txt file below from one crash shows an out of memory situation related to sound driver. The GizmoLog.txt file is from the next test without SilverLining but does show an error. Log_saab340a_ctd_10_mem_err.txt GizmoLog.txt

I just noticed today your post about Skunkcrafts Updater. I removed it from my fully loaded X-Plane configuration, leaving in all the other plugins, including Skymaxx Pro. I let it sit for 40 minutes after loading the LES Saab 340A and no crash. I was able to start up the engines and complete a flight from LEZL to LEMG. Yay. I don't mind removing that particular plugin since I don't like how it works in the first place, so for me it's an acceptable workaround -- unlike removing SkyMaxx Pro, which I like to use quite a bit. This doesn't really resolve why only the Saab 340A is affected or why it's only affected when there is lots of custom scenery loaded, but at least I can fly the Saab with HD orthophoto scenery, custom airports, and real weather as supported by SkyMaxx Pro.

Some of those Ground Traffic plugin instances may be more than five years old. There's a chance for some sort of conflict there. How it would interact with SkyMaxx Pro and LES Saab 340A are a mystery to me. Perhaps one undoes some initialization that another set up? And why only with the Saab and SkyMaxx combination? And why don't other Saab + Skymaxx users see the same issue? I imagine a lot of LES Saab 340A + Skymaxx Pro customers have as much or more custom scenery as I do. The must unique thing about my setup is an AMD Ryzen 7 1800X 8-core processor plus I use Process Lasso to spread X-Plane execution across more threads than most users would be using. However, it hasn't caused issues with other X-Plane aircraft, so far. The crash scenario behaves a lot like a memory leak since the crash occurs after a relatively consistent amount of time (about 15 minutes), yet, watching memory usage in Task Manager, I don't see a gradual consumption of memory. There could be some event at that point that triggers some massive grab of memory and there just isn't that amount available if SkyMaxx Pro also is running? Is there some sort of trace flag I can turn on to try to get more info to diagnose what's happening?

After much testing of my stripped down copy of X-Plane with the LES Saab 340A and just Western US scenery, no crashes occurred and I could have all plugins installed -- no problem. However, I then made a symbolic link from "Custom Scenery" to my normal fully loaded "Custom Scenery" and the crashes immediately started occurring again, even without trying to start the engines. Then, after removing all the plugins except Gizmo64, I could start and fly the Saab 340A once again no problems. So, there is some interaction between having a ton of custom scenery and having all the plugins I normally use. I suspect I could add back all the plugins except SkyMaxx Pro and it would keep working (as before). Any further suggestions? PS: I note that I have 54 instances of the Ground Traffic plugin because many airports include that. It's a pity they can't all share one instance. Log_saab340a_ctd01bb.txt Log_saab340a_ctd02bb.txt GizmoLog_saab340a_ctd01bb.txt GizmoLog_saab340a_ctd02bb.txt

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.

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.

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

Adding GizmoLog.txt and Log.txt after 7th crash. Crash happens while I'm manually going through the engine startup sequence -- usually after I've got then engines running and have advanced the condition levers to Max. GizmoLog_saab340a_ctd_07.txt Log_saab340a_ctd_07.txt

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

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.

I agree. Very stable ground handling now. No problem at all. Thanks, developers!

There are some liveries by Razor94 that modify the light switches, putting white dots on the edge that show when the switch is ON. Probably not realistic, but it is very effective. Perhaps a config option could turn that feature off for those who want true realism.

Check your Maintenance Manager screens. Something may need repair.

Side bar disappears for me in full screen mode. But, if I switch to windowed mode, the side bar re-appears. Only happens in XP11.30b5 version. In XP11.26r2 the side bar is OK.

WORKAROUND: I found that I can create the flight plan with user waypoints in littlenavmap, export them to .fms format, and load them into the G1000. In littlenavmap, I give each user waypoint a custom name. When I load the flight plan into the G1000, the custom waypoints look like ordinary waypoints.

Seems not possible at the present time. One can cycle between MAP, WPT, and NRST by moving the large FMS knob when at the map on the MFD. However, within WPT one should be able to turn the small FMS knob to select "USER WPT INFORMATION", but the only option is "AIRPORT INFORMATION", and even that doesn't work -- it just shows KLAX and you can't change it. Any suggestions?

Yes. Seems most of the time it stays where I set it. Sometimes or often goes to AUTO.

I have this one. Seems good, though I don't know how accurate it is. There's even a flight risk assessment that considers such human factors as inadequate rest, illness, personal relationship issues, and many other factors.

There a gray TOD dot that should be drawn on the map display that also is missing, I think. At least, I've never seen it despite using VNAV many times.