1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Memory leaks ?

Discussion in 'Gauges' started by Geoff_D, 13/3/11.

  1. Geoff_D

    Geoff_D

    Joined:
    5/2/07
    Messages:
    358
    Country:
    unitedstates
    Disclaimer: I know NOTHING of significance about GMAX, or making FSX aircraft.

    My question is,

    Can an addon plane, made with GMAX, and XML gauges (ie No C gauges), have a "Memory leak"

    I ask, because I plane I am testing, seems to cause FSX to just keep increasing, and inceasing to use more memory, till FSX crashes.

    (XP Pro 32 bit. On W7, 64, I just see the memory for FSX grow, ie now at 1.2 gigs and still climbing. Other planes, it settle down at aboyr 0.5 gig )


    Other aircraft are not doing this, so it appears to be connected with this particular aircraft.

    If YES, and idea how to isolate and fix the leak. Typical things to llok for ??

    Geoff
  2. scruffyduck

    scruffyduck Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    17/9/05
    Messages:
    24,130
    Country:
    wales
    If you have eliminated everything else then the plane appears to be the culprit. As to why and what. Memory leaks are usually caused by some code that repeatedly creates a memory using object, or fails to dispose of used objects. In the world of programming we have managed and unmanaged dode. Managed languages like C# or VB.Net are supposed to take care of disposal when some object is finished with. However this is not all that reliable. In unmanaged code (C being a good example) then the programmer needs to ensure that objects that are finished with are disposed of themselves.

    Graphics tend to be unmanaged. ADE has had a memory leak for a long time and we have never really solved it (well we think we might have for the next version)

    This is a long way round to say that it is possible your aircraft is leaking. AS to finding it - well that would be a bit difficult. Perhaps the easiest is to go back to the designer (unless it is your design)

    The usual way to find these things is to run a memory profiler. I ma not sure there are any free ones around. I use ANTS. You start with a snapshot of the application before running the suspect code - in this case loading you plane) and then load it and wait a while. Another snapshot or two will tell you what is growing (hopefully). I have never tried to run a memory profiler on FS however so I do not know if it would be that easy to do.
  3. arno

    arno Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    28/5/04
    Messages:
    21,237
    Country:
    netherlands
    Hi,

    The geometry of the aircraft, made with GMax, can not really have memory leaks. The MDL format has a quite strict definition. So I would expect such a leak to be in the more dynamic parts of the aircraft, e.g. gauges.
  4. scruffyduck

    scruffyduck Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    17/9/05
    Messages:
    24,130
    Country:
    wales
    I would certainly agree with that. Are there any dll files installed with this aircraft? If so then they will contain code that may give rise to leaks
  5. Geoff_D

    Geoff_D

    Joined:
    5/2/07
    Messages:
    358
    Country:
    unitedstates
    No C gauges.. ie no .dll gauges.

    ALL Gauges are XML, both 2D & 3D.

    So, either GMAX is leaking, or XML is leaking.

    Since is should be quite difficult to write XML that by design, is leaky, I must assume that if it is an XML leak, it is in the XML interpreter ?

    Scruffy mentioned that GMAX is know to have potential memory leaks. (or was that just his ADE application ) ?
    That may be it.

    I have tried using Memory Profilers with FSX.... with varying success.
    FSX is such a HOG !! My PC is not the fastest, and eveything slows down to a crawl.

    I am not the designer, but I am trying to assist the designer in solving the PC instability issues of their plane, which is even more prone to PC crashing and lockup, when in Multiplayer mode.

    So yes, we do have 3D Model source & XML available.

    Maybe its a question of elimination. Remove all Gauges, and if the leak stops, add them back in one at a time (or howerver), to find the one that is causing the issues ... ??

    Any suggestions would be most welcome.

    Geoff
    Last edited: 13/3/11
  6. scruffyduck

    scruffyduck Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    17/9/05
    Messages:
    24,130
    Country:
    wales
    Hi Geoff

    It sounds like the process of elimination is likely to be the best way. I am not aware of leaks with GMax - it is ADE that I refer to.
  7. n4gix

    n4gix Resource contributor

    Joined:
    26/9/06
    Messages:
    9,216
    Country:
    unitedstates
    Oh dear! That is certainly not the case at all. In fact, it is the single most frequent boo-boo possible to make!

    Are you familiar with the term "race condition?" It is a classic error whereby a careless (or ignorant) programmer has an event firing continuously with no check and/or stop routine whatsoever... :eek:

    Consider for a moment what the effect would be of sending a command to the sim eighteen times per second, such as:

    (>K:MIXTURE1_RICH)

    Q1: Would you ever be able to lean the mixture?
    Q2: Can any other events be triggered?

    A1: No, since any attempt that did manage to be sent would be cancelled.
    A2: Possibly, but not with a high chance of success.

    The classic symptom in the sim is that one is unable to complete any "set commands," that is commands that require a second immediate keystroke, such as Shift-E,2. These "set commands" wait for around 2 seconds for another key input before defaulting to "1."

    In FSX, because of an error in coding the bounding box of the "fuel stations," parking an aircraft in the closest parking area will frequently result in the door snapping shut immediately after opening. This is because the fuel station's bounding box is constantly triggering a "fill tanks full" command!

    The real downside to a "race condition" is that for every command triggered, a new memory handle is created! Worse, since the majority of the commands are never executed, the handles do not get destroyed!!!

    If you monitor the system's resources, you'll see the handle count increasing continuously. Eventually, the handle count will completely flood available memory space and... BOOM!

    Now, since the XML scripts for 3d "gauges" are contained in the compiled model itself, if a "race condition" has been mistakenly been created, there is absolutely nothing anyone without the source file can do to fix it!

    Years ago Doug Dawson wrote a diagnostic utility gauge that will track and report every event sent by a gauge, whether C or XML:

    event_logger.gau (available at AVSIM, Flightsim.com and elsewhere).

    Once installed via panel.cfg file, and launching the a/c in question, record about 10 seconds or so, then stop recording, pause the sim, then load the event log in notepad and look for repeating events.
    Last edited: 13/3/11
  8. Geoff_D

    Geoff_D

    Joined:
    5/2/07
    Messages:
    358
    Country:
    unitedstates
    Bill,

    Thank you yet again, for such a detailed response, and for sharing your wealth of information with us.

    The "Gauge Event Logger" sounds like a great direction to go in.
    ( Thank you too, Doug Dawson )

    I am now doubly excited, as Doug's "Gauge Event Logger" may also throw some light on the Microsoft Tower Radar "Session Info" Gauge, that also seems to have the characteristic of eventually hanging the sim, after some time of use.

    My only delimer now is which one to look at first... Plane or Radar... !!!

    Geoff
    Last edited: 14/3/11
  9. Geoff_D

    Geoff_D

    Joined:
    5/2/07
    Messages:
    358
    Country:
    unitedstates
    HELP --

    After far too many hours of messing about, I still cannot get the "Event Logger" to run. All I get is a Black window. No text or buttons inside,

    Clicking all over it, does not result in anything being logged.

    I see it is dated 2006. Does it really work with FSX SP2/Accel ??

    Geoff
  10. Gypsy Baron

    Gypsy Baron

    Joined:
    4/3/07
    Messages:
    152
    Country:
    us-california
    Geoff,
    I use the "updated" gauge "fsx_event_logger.gau" , dated 12/27/2006 in FSX to check for the presence of mal-programmed gauges.

    I don't recall exactly where I downloaded it from but a Google search
    should get you there.

    BTW, the gauge was created by Doug Dawson...not Pete Dowson :)

    Paul
  11. Geoff_D

    Geoff_D

    Joined:
    5/2/07
    Messages:
    358
    Country:
    unitedstates
    Well, thats the one I have, but I cannot get to work. !!!
    Not for want of trying.
    Tried 2 computers, several Aircraft.

    First time I call it after load an aircraft, I get a Black Box flash up on the screen, then thats it. Cannot be evoked again to even flash, till I reload aircraft.


    Any help would be appreciated.

    Is Doug Dawson still active in the FS community ??

    Geoff
  12. Gypsy Baron

    Gypsy Baron

    Joined:
    4/3/07
    Messages:
    152
    Country:
    us-california
    Did you install the gauge statement in an existing window?

    I usually attach that gauge to an existing window, increasing the
    window size to accommodate the event logger control panel.
    Just make sure you increase the size of the window enough.

    The entry is, of course, just the standard form.

    gaugexx=fsx_event_logger!event_logger, x , y, 125, 60

    I do not recall having to do anything special to get the gauge
    to function. That said, I have seen the "black window flash
    momentarily" on occasions with other windows I was tweaking
    but do not recall what I did wrong to cause that action.

    You could, of course, create a new window dedicated to this
    little 125x60 control panel and that should work as long as
    the Windowxx parameters are correct and you declare the
    window in the Window Titles section of the panel.cfg file.

    Paul
  13. Geoff_D

    Geoff_D

    Joined:
    5/2/07
    Messages:
    358
    Country:
    unitedstates
    Paul

    yes, tried all that :)

    The gauge tries to display, and the window flashes up, but then it dissapears after a fraction of a seconds -- typical of a Guage that has an error in it.

    In frustration, and to get the job done, I remembere that the Registered FSUIPC has an event logger buit in. Even nicer, as it will log events without having to add anything to each simobject.
    You can also see the Events logging in Real time to a console window.

    So This time I CAN say '' Thanks PETE DOWSON !!!

    Found the rouges Events, from faulty XML in the model, and occuring at Frame Update rate. No wonder thing were getting Bogged down!!!

    Thanks for pointing me in the right direction Bill....

    Geoff
  14. n4gix

    n4gix Resource contributor

    Joined:
    26/9/06
    Messages:
    9,216
    Country:
    unitedstates
    Okay, given that you've identified the rougue event, it might be possible using Visual Studio to load the model into it's hex editor, search for the rogue event (carefully), then deliberately cripple the event code by replacing the > character with either a space or some random letter.

    If it turns out that the event really needs to be fired for some operational reason, then one could quite probably write a tiny XML scripted "gauge" that would fire the event under controlled conditions.
  15. Gypsy Baron

    Gypsy Baron

    Joined:
    4/3/07
    Messages:
    152
    Country:
    us-california
    Ah, I also forgot about the FSUIPC logging capability in this context.
    I generally don't use it for the 'real time' display as on my monitor the
    text is too small and scrolls too fast to be of use to me. I do use the
    text log when doing debugging though. I like the fsx_event_logger
    since I can turn it on/off without resorting to the FSUIPC drop-down
    menu and I can get a rough visual idea of the rate at which events
    are occurring by watching it's counter. The more tools the merrier :)

    Paul
  16. Geoff_D

    Geoff_D

    Joined:
    5/2/07
    Messages:
    358
    Country:
    unitedstates
    Bill

    Even easier --- having Identified the cause of the Memory leak, I informed the developer as to exacly what was wrong with their XML, who fixed the issue in a a few minutes, and produced a beta MDL, that had the issue corrected.

    But yes, Hacking a Mdl is not that big a deal-- very little protection to stop one doing that.... but its best avoided if you can get someone else to fix their own mistakes. :)

    BTW: Talking of MDL files. I have never actually made / compiled one, but the ones that did examine, I could clearly see the places where the XML code was. What seems strange was the masses of SPACES in the compiled MDL, in the XML areas. I would have expected the compiler to have optimized the XML, to remove all unnecessary spaces.

    Spaces are nice in the SOURCE xml, to make it eaiser for human to read, but is wasted in the final xml that is to run.

    Even a Pre-processor, to process XML before it gets put into the MDL, MIGHT have efficeiency advantages ?? Same for any XML.

    Would optimizing the XML by removing spaces make much difference to execution speed ? Similarly, would using short-name User variables improve speed significantly ?

    Certainly having masses of spaces, makes it far easier to edit and modify the XML in the MDL, with your Friendly Hex editor !!

    Are there any tools for profiling XML execution, to determine bottlenecks, and evaluate different methods of achieving the same thing, so one can more easily optimize the performace of the XML. Some FSX Xml I have looked at is alarmingly inefficient, and could be written to be far more efficient :D


    I will confess I have edited a few pieces of .MDL XML in some addons, to stop them causing issues... no names mentioned !!!

    Geoff

Share This Page