[Interest] Is here memory leaks?

Thiago Macieira thiago.macieira at intel.com
Fri Oct 9 01:20:23 CEST 2015


On Thursday 08 October 2015 23:40:10 Till Oliver Knoll wrote:
> > Am 08.10.2015 um 22:21 schrieb Thiago Macieira
> > <thiago.macieira at intel.com>:
> > .... Leaks-because-of-exit don't
> > count, except for pedantism.
> 
> Sorry to be pedantic one here, but leaks mean that d'tors are not called,
> even when at process exit memory is reclaimed by the OS. And not calling a
> d'tor could imply that not just memory is leaked, but other resources, too.
> E.g. file locks could remain in place (even though I think most/all OSs
> also reclaim open file descriptors, but not sure...), network connections
> could be terminated "unexpectedly", transactions could remain open etc.

I never claimed that those weren't a problem.

But look at the backtraces that Igor posted. Most of the benign leaks are from 
C code, usually in the form of a static variable that gets initialised once 
per execution. Valgrind considers them leaks because the library got unloaded 
and, thus, the variable that had the pointer is gone. If the library hadn't 
been unloaded, Valgrind would have said "still reachable"

> Not saying that this is the case with Qt objects, but I am the pedantic one
> who deletes (tries to ;)) every single object that got allocated in my code
> at program exit...

I'm all for a clean exit, but I don't want to execute more than I need to. 
Some types of cleanup can be left for later, after the program exits.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Interest mailing list