È normale che l'esecuzione di python con valgrind mostri molti errori con la memoria?

Question

Ho provato a eseguire il debug di crash della memoria nella mia estensione Python C e ho provato a eseguire script in valgrind. Ho trovato c'è troppo "rumore" nell'output valgrind, anche se io ho fatto funzionare semplice comando come:

valgrind python -c "" 

uscita Valgrind pieno di informazioni ripetute in questo modo:

==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 su Slackware 12.2.

È un comportamento normale? Se è così allora valgrind forse è uno strumento inappropriato per il debug degli errori di memoria in Python?

Answer 1

si potrebbe provare a utilizzare il suppression file che viene fornito con la fonte di pitone

Leggendo la Python Valgrind README è una buona idea troppo!

Answer 2

Sì, questo è tipico. I sistemi di grandi dimensioni spesso lasciano libera la memoria, il che va bene fintanto che è una quantità costante e non proporzionale alla cronologia di esecuzione del sistema. L'interprete Python rientra in questa categoria.

Forse è possibile filtrare l'output di valgrind per mettere a fuoco solo le allocazioni effettuate nell'estensione C?

Answer 3

Questo è abbastanza comune, in qualsiasi sistema di grandi dimensioni. È possibile utilizzare di Valgrind suppression system per sopprimere in modo esplicito gli avvertimenti che non siete interessati a.

Answer 4

C'è un'altra opzione che ho trovato. James Henstridge ha una compilazione personalizzata di python che può rilevare il fatto che python è in esecuzione con valgrind e in questo caso l'allocatore di pymalloc è disabilitato, con PyObject_Malloc/PyObject_Free che passa al normale malloc/free, che valgrind sa come tracciare.

pacchetto disponibile qui: https://launchpad.net/~jamesh/+archive/python

Answer 5

L'opzione più corretta è quella di dire Valgrind che dovrebbe intercettare funzioni di allocazione di Python. Si dovrebbe correggere valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c aggiungendo i nuovi intercettori per PyObject_Malloc, PyObject_Free, PyObject_Realloc, ad esempio:

ALLOC_or_NULL(NONE,     PyObject_Malloc,  malloc); 

(Si noti che il soname per funzioni di allocazione agli utenti dovrebbe essere NONE)