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
