zakalawe wrote in Fri Jan 31, 2014 11:29 pm:Another possibility would be if some instrument or feature we're using the in C172 burns memory - eg tool tips / canvas. All of these options seem unlikely - if tool tips leaked a megabyte per tooltip shown, you would still need to see thousands to cause a memory shortage.
It's very odd.
agreed, I once talked with Stuart and TheTom about also adding details about the amount of physical RAM vs. swap usage, too - having these things available in FG, would make troubleshooting around here quite a bit easier, and would also allow us to do feature-scaling, I provided a patch for this for a Linux implementation back then, and we could probably extend this for all main OS (win, mac, linux):
viewtopic.php?f=5&t=16083&p=165168#p164936As can be seen, we specifically talked about subsystem-specific RAM usage tracking (random buildings, canvas, autopilot, replay/flight recorder etc) -analogous to ThorstenB's system monitor, just with a focus on RAM (memory).
Possibly via some custom smart pointer implementation that overloads new/delete - the main issue being that we really need a way to track memory usage per subsystem, so that we can identify "rogue" features - either to fix them, or to provide hooks for feature-scaling purposes.
For Nasal space, we pretty much have a working solution that could help us identify scripts that are causing lots of new naRefs or temporaries. But C++ code is a different beast, and as can be seen in many discussions here - we have quite a few people with >= 8gb of RAM seeing crashes on 64 bit OS due to "out of RAM" errors.
There's also many other examples for this, such as the v2 scenery eating up tons of RAM without anybody noticing, until the atlas developer pointed this out:
viewtopic.php?f=5&t=21498&p=195610&hilit=#p195610So for post 3.0, we should probably investigate how to track RAM per subsystem/feature and provide some "live" stats.
EDIT:
http://wiki.flightgear.org/Subsystem-le ... FlightGear