I don't see *how* we can clean it up. We could register an atexit handler which tears down everybody's classes, but then we're just doing work for no reason: the OS will clean up our memory in any case.
The issue seems to be "I'm using valgrind and it mentions a lot of 'possibly lost' data." In which case, we should probably improve this output -- perhaps keep more references around or use valgrind macros so it doesn't confuse it that much. In the meantime, you can use a valgrind suppressions file. I thought we had a maintained one in glib, but I can't find it right now, so I'll give you the generic one we use for the gjs test mechanism. https://git.gnome.org/browse/gjs/tree/installed-tests/extra/gjs.supp On Tue, Feb 10, 2015 at 1:34 AM, John Emmas <j...@creativepost.co.uk> wrote: > On 10/02/2015 08:37, Norman, Anders wrote: > >> The base class is simply never cleaned up. Typical types registered with >>> GType are static, meaning they aren't ever cleaned up for the entire >>> duration of the process. >>> >>> Why do you need to clean up the type? >>> >> I'm making a framework which other developers will use to create >> applications. Yes, I can tell the developers to ignore the leak, but I >> think the question should be the other way around: Why do you need to leak >> this memory? >> >> > As someone else who's previously complained about glib's memory leaks, > I'll admit that I'm with Anders on this one. > > Okay - the developers are technically correct in saying that these > particular leaks don't (of themselves) cause a problem. The problem is > that they make it extremely difficult to find genuine leaks in one's own > code. If we were only talking about a few leaks here and there (in glib) > that might be workable - but in fact, glib has many hundreds of such > leaks. This makes it near impossible to find other leaks - even if you > have leak detection software available. > > And here's an even worse scenario... a program allocates some memory, > then frees it but then carries on accessing the freed memory. MSVC is at > least helpful in this respect - since your program will crash on any > machine you care to run it on. But gcc is much too tolerant in that > situation. So what you end up with is an app that's troublesome and > unreliable on one user's machine - and yet it seems to run perfectly on > somebody else's. > > In ANY glib based app, finding problems like these is made unnecessarily > difficult - just because of the sheer number of leaks in glib itself. > Surely that's a good enough reason for getting rid of them? > > John > > _______________________________________________ > gtk-list mailing list > gtk-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-list > -- Jasper
_______________________________________________ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
