Antoine Pitrou <pit...@free.fr> added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13390> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
