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@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list
