Re: Memory leak in gdbus-codegen generated code

[John Emmas <john creativepost co uk>]

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