¿Es normal que ejecutar python bajo valgrind muestre muchos errores con la memoria?

Question

He intentado depurar el bloqueo de memoria en mi extensión de Python C e intenté ejecutar el script en valgrind. He encontrado que hay demasiado "ruido" en la salida valgrind, incluso si he encontré con comandos simples como:

valgrind python -c "" 

salida Valgrind lleno de información repetida de esta manera:

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

¿Es normal el comportamiento? Si es así, ¿entonces valgrind es una herramienta inapropiada para depurar errores de memoria en Python?

Answer 1

Usted podría tratar de usar la suppression file que viene con la fuente pitón

Lectura de la Python Valgrind README es una buena idea también!

Answer 2

Sí, esto es típico. Los sistemas grandes a menudo dejan la memoria sin liberar, lo que está bien siempre que sea una cantidad constante y no proporcional al historial de funcionamiento del sistema. El intérprete de Python entra en esta categoría.

Quizás pueda filtrar la salida de valgrind para enfocar solo las asignaciones hechas en su extensión C?

Answer 3

Esto es bastante común, en cualquier sistema grande. Se puede utilizar de Valgrind suppression system para suprimir las advertencias explícitamente que no está interesado.

Answer 4

Hay otra opción que encontré. James Henstridge tiene una compilación personalizada de python que puede detectar el hecho de que python se ejecuta bajo valgrind y en este caso el asignador pymalloc está deshabilitado, con PyObject_Malloc/PyObject_Free pasando a malloc/free normal, que valgrind sabe cómo rastrear.

paquete disponible aquí: https://launchpad.net/~jamesh/+archive/python

Answer 5

La opción más correcta es decirle Valgrind que debería interceptar las funciones de asignación de Python. Debe parchear valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c la adición de los nuevos interceptores para PyObject_Malloc, PyObject_Free, PyObject_Realloc, por ejemplo:

ALLOC_or_NULL(NONE,     PyObject_Malloc,  malloc); 

(Tenga en cuenta que el soname para las funciones de asignación de usuarios debe ser NONE)