Hi Erik On Sunday 14 October 2007 10:28, Erik Hofman wrote: > If memory servers me well I would think those are freed using the > atexit() mechanism. It could well be that valgrind doesn't work up to > that point to detect it though. >
It looks like the current exit calling sequence is something like this (from valgrind, after hitting the file menu exit|okay button): ==22044== by 0x807179B: FGGlobals::~FGGlobals() (globals.cxx:120) ==22044== by 0x8051D21: fgExitCleanup() (bootstrap.cxx:246) ==22044== by 0x450ABCC: exit (in /lib/libc-2.5.so) ==22044== by 0x808210A: fgExit(int) (util.cxx:108) ==22044== by 0x805FB43: do_exit(SGPropertyNode const*) (fg_commands.cxx:226) ==22044== by 0x8321F80: FGBinding::fire() const (input.cxx:157) ==22044== by 0x82F72BB: action_callback(puObject*) (dialog.cxx:265) ==22044== in ~FGGlobals(), some of the global data structures were freed, but most of them weren't. Admittedly, at this stage of program shutdown deallocating memory isn't as critical, but in light of recent rather bizarre memory allocation observations, I'd like to make this as tight as possible, in the hope of eventually uncovering what's happening Cheers, Durk ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
