Message 147672 - Python tracker (original) (raw)

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.