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 <john@xxxxxxxxxxxxxxxxxx> 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.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?
Why do you need to clean up the type?
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@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list
--
Jasper
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
