Re: reclaiming memory before exit, take 2

[Bruno Haible]

Hi Paul,

> > The QA automation needs to rely on the suppression files created by the
> > developers, since it's not a QA engineer's job to evaluate whether a
> > particular memory leak is serious or not.
> 
> This division of labor is not universal. In many shops, QA engineers are more
> involved in determining the seriousness of bugs, and they can maintain
> suppression files.

Indeed. It's a continuum. It can very well be the QA engineer who determines
the seriousness of a leak and proposes suppressions to the developer.

> > On the contrary, reporting leaks through global and static variables is
> > a feature. *Hiding* them, which is what the tools do by default, is a
> > *misfeature*.
> 
> This depends on what sort of leaks you're looking for. I agree that these are
> very often leaks, and that it generally makes sense to look for them. 
> However, I
> don't think we always need to worry about these leaks just before program 
> exit,
> since they are not a performance problem there and introducing 'free' there 
> both
> complicates and slows the program.

I'm not sure I understand what you mean.

We agree that, in the production binaries, it is a waste of computer resources
to free the memory references stored in global and static variables.

Are you suggesting that developers should ignore the global and static
variables, i.e. not use --show-reachable=yes? If so, what would be the 
advantage,
compared to the suppressions file approach?

Are you suggesting that QA automation should ignore the global and static
variables?

Bruno