> Valgrind does a much better job at this: it will also show you where
> the leaked blocks were allocated.
> OTOH, Valgrind is Linux-only and slow, but since I haven't used the
> '-R' option much, I don't know how usable this will be in practice
> (detecting memory leaks is one thing, identifying them is even
> better :-).

Yes, Valgrind is much more exhaustive and precise, but you have to build
Python --with-valgrind, to find the correct options to pass to Valgrind,
and also to parse the output. For example, OpenSSL seems to cause lots
of errors such as:

==20599== Conditional jump or move depends on uninitialised value(s)
==20599==    at 0xA2BB0B3: BN_div (in /usr/lib64/libcrypto.so.1.0.0)
==20599==    by 0xA2C125E: BN_nnmod (in /usr/lib64/libcrypto.so.1.0.0)
==20599==    by 0xA2C15CD: BN_mod_mul (in /usr/lib64/libcrypto.so.1.0.0)
==20599==    by 0xA2C37F0: BN_BLINDING_convert_ex
(in /usr/lib64/libcrypto.so.1.0.0)
==20599==    by 0xA2E15D6: ??? (in /usr/lib64/libcrypto.so.1.0.0)
==20599==    by 0x9FE6363: ssl3_get_client_key_exchange
(in /usr/lib64/libssl.so.1.0.0)
==20599==    by 0x9FE83A7: ssl3_accept (in /usr/lib64/libssl.so.1.0.0)
==20599==    by 0xF804190: PySSL_SSLdo_handshake (_ssl.c:390)
==20599==    by 0x47C0E9: PyEval_EvalFrameEx (ceval.c:3985)
==20599==    by 0x47CAC3: PyEval_EvalCodeEx (ceval.c:3376)
==20599==    by 0x47B3F1: PyEval_EvalFrameEx (ceval.c:4099)
==20599==    by 0x47C1DB: PyEval_EvalFrameEx (ceval.c:4089)

Right now this patch will allow to enrich the daily refleak runs (those
that send an e-mail to python-checkins). If someone finds a way to
sanitize Valgrind output, a daily Valgrind run would be cool as well.