[Development] Qt's Leak-on-exit policy

Thiago Macieira thiago.macieira at intel.com
Wed Dec 18 01:22:33 CET 2013


On terça-feira, 17 de dezembro de 2013 15:42:36, Alex Montgomery wrote:
> In QtQuick, QSGRenderLoop::instance() can create a QSGWindowsRenderLoop
> using new that it never destroys. The memory is always pointed to by a
> static member pointer, so it's never "lost" exactly, but the memory is
> never freed by Qt (but hopefully will be by any decent OS). Is this a bug?
> Should Qt libs bother freeing memory on exit, or is this an unnecessary
> expense?

> Should Qt clean-up dynamically allocated reachable pointers, or is this
> useless / pointless work?

To bring a little more background from the discussion, I said there are three 
types of leaks:

1) dynamic leaks, which is when old pointers are lost (overwritten) and more 
memory gets allocated during the runtime of the application

2) static leak, which is when the pointer is overwritten at shutdown without 
being freed

3) reachable pointers

Dynamic leaks must be fixed. I'd argue that we should fix static leaks by either 
leaving the pointers reachable or by actually freeing, if it's not too much 
trouble.

As for the reachable pointers, they should be investigated. Objects not 
properly destroyed at shutdown could be an indication of something else wrong, 
like files not saved, work not performed or interrupted early, etc.

If it turns out that the failure to destroy is harmless, I'm not sure we 
should do anything. If it's harmless, that means the extra work required to 
free the memory is wasted, since it has no benefit to anyone. Just wasted CPU 
cycles.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131217/ef3936bc/attachment.sig>


More information about the Development mailing list