> On 13 Mar 2018, at 23:53, amon <[email protected]> wrote: > > Perhaps someone can tell me if my guess on the following is > correct. After an afternoon of trying to figure out where the > large number of leaks reported by valgrind were coming from, I > went all the way back to basics. What it seems to show is that > the GNUStep run time allocates a bunch of stuff at start up and > never clears it.
Yes, there's a whole lot of stuff cached ... not just on startup but also on demand (ie the first time the program uses some feature). If you look at the NSObject extensions documentation (or the GNUstep/NSObject+GNUstepBase.h header) you will see festures for handling cleanup of that sort of thing on process exit. Be aware though that, because it's normally a bad idea to explicitly free stuff on exit, cleanup is not normally enabled (with the +setShouldCleanUp: method or the GNUSTEP_SHOULD_CLEAN_UP environment variable) so it's a relatively untested feature and is definitely incomplete (many classes that could support cleanup of their cached information just don't implement it). If you are interested in contributing additional cleanup code it would be welcome for those cases where people want to use valgrind on processes that terminate. Mostly I deal with code that runs 24x7 so cleanup of cached memory is not an issue and I only worry about actual leaks, but it's reassuring to have valgrind tell you that a process frees all memory before exit anyway. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
