Ist es normal, dass das Ausführen von Python unter valgrind viele Fehler mit dem Speicher zeigt?

Question

Ich habe versucht, Speicherabsturz in meiner Python C-Erweiterung zu debuggen und versucht, Skript unter Valgrind auszuführen. Ich fand es zu viel „Lärm“ in der valgrind Ausgang, auch wenn ich einfach Befehl ausgeführt haben, wie:

valgrind python -c "" 

Valgrind Ausgabe voller wiederholt Informationen wie folgt aus:

==12317== Invalid read of size 4 
==12317== at 0x409CF59: PyObject_Free (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x405C7C7: PyGrammar_RemoveAccelerators (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x410A1EC: Py_Finalize (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x4114FD1: Py_Main (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x8048591: main (in /usr/bin/python2.5) 
==12317== Address 0x43CD010 is 7,016 bytes inside a block of size 8,208 free'd 
==12317== at 0x4022F6C: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) 
==12317== by 0x4107ACC: PyArena_Free (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x41095D7: PyRun_StringFlags (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x40DF262: (within /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x4099569: PyCFunction_Call (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x40E76CC: PyEval_EvalFrameEx (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x40E70F3: PyEval_EvalFrameEx (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x40E896A: PyEval_EvalCodeEx (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x40E8AC2: PyEval_EvalCode (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x40FD99C: PyImport_ExecCodeModuleEx (in /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x40FFC93: (within /usr/lib/libpython2.5.so.1.0) 
==12317== by 0x41002B0: (within /usr/lib/libpython2.5.so.1.0) 

Python 2.5. 2 auf Slackware 12.2.

Ist es normales Verhalten? Wenn ja, dann ist Valgrind vielleicht ein ungeeignetes Tool zum Debuggen von Speicherfehlern in Python?

Answer 1

Sie könnten versuchen, die suppression file verwenden, die

Lesen der Python Valgrind README ist eine gute Idee, auch mit der Python-Quelle kommt!

Answer 2

Ja, das ist typisch. Bei großen Systemen wird der Speicher häufig nicht freigegeben, was in Ordnung ist, solange es sich um einen konstanten Betrag handelt und nicht proportional zum laufenden Verlauf des Systems. Der Python-Interpreter fällt in diese Kategorie.

Vielleicht können Sie die Valgrind-Ausgabe filtern, um sich nur auf Zuweisungen in Ihrer C-Erweiterung zu konzentrieren?

Answer 3

Dies ist ziemlich üblich, in jedem größeren System. Sie können suppression system Valgrind die Verwendung ausdrücklich Warnungen zu unterdrücken, die Sie nicht interessieren.

Answer 4

Es gibt eine andere Option, die ich gefunden habe. James Henstridge hat einen benutzerdefinierten Build von Python, der die Tatsache erkennen kann, dass Python unter valgrind läuft und in diesem Fall pymalloc allocator deaktiviert ist, wobei PyObject_Malloc/PyObject_Free zu normalem malloc/free übergeht, was valgrind weiß, wie es zu verfolgen ist.

Paket verfügbar hier: https://launchpad.net/~jamesh/+archive/python

Answer 5

Die richtige Option ist Valgrind zu sagen, dass es Python Zuordnungsfunktionen abfangen sollte. Sie sollten Patch valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c Hinzufügen der neuen Abfangjäger für PyObject_Malloc, PyObject_Free, PyObject_Realloc, zB:

ALLOC_or_NULL(NONE,     PyObject_Malloc,  malloc);