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

[Thiago Macieira]

On quarta-feira, 18 de dezembro de 2013 17:03:56, Alex Montgomery wrote:
> I especially like the idea of creating an ignore list for valgrind if we
> could use it for unit tests. Then at least people would have to be
> conscious about the memory leaks they create and add them to the valgrind
> ignore list if they are intentional.

Hardcoding them in the binary via VALGRIND_FREELIKE_BLOCK might be even 
better.

The only problem I have with valgrind hardcoded info is that they still cost 
execution. This is what VALGRIND_FREELIKE_BLOCK expands to:

        movq    $4866, -56(%rsp)
        leaq    -56(%rsp), %rax
        movq    %rdi, -48(%rsp)
        xorl    %edx, %edx
        movq    %rsi, -40(%rsp)
        movq    $0, -32(%rsp)
        movq    $0, -24(%rsp)
        movq    $0, -16(%rsp)
#APP
# 1 "<stdin>" 1
        rolq $3,  %rdi ; rolq $13, %rdi
        rolq $61, %rdi ; rolq $51, %rdi
        xchgq %rbx,%rbx
# 0 "" 2
#NO_APP

So we can't leave those on for release builds.

Then again, from past experience, release builds are unvalgrindable anyway due 
to the compiler being smarter than valgrind (GCC replaces strlen() calls with 
an inline version that can safely read past the end of the string).

-- 
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/20131218/70271c1e/attachment.sig>