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

debugging memory-leaks

Question

He intentado depurar el bloqueo de memoria en mi extensión Python C y he intentado ejecutar el script bajo valgrind. Descubrí que hay demasiado "ruido" en la salida de valgrind, incluso si ejecuté un comando simple como:

valgrind python -c ""

Salida de Valgrind llena de información repetida como esta:

==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 el comportamiento normal? Si es así, entonces valgrind es una herramienta inadecuada para depurar errores de memoria en Python.

Answer 1

Esto es bastante común, en cualquier sistema grande. Puede usar el sistema de supresión de Valgrind para suprimir explícitamente las advertencias que no le interesan.

Answer 2

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 de pymalloc está deshabilitado, con PyObject_Malloc / PyObject_Free que pasa a malloc / free, que valgrind sabe cómo rastrear.

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

Answer 3

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

ALLOC_or_NULL(NONE,                  PyObject_Malloc,      malloc);

(tenga en cuenta que las funciones de asignación de soname para usuarios deben ser NONE )

Answer 4

Puedes intentar usar el archivo de supresión que viene con la fuente de Python

¡Leer el Python Valgrind README también es una buena idea!

Answer 5

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

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

Answer 6

Siguiendo los enlaces proporcionados por Nick, pude encontrar algunas actualizaciones en README.valgrind . En una palabra, para Python> 3.6, puede configurar la variable de entorno PYTHONMALLOC=malloc para desactivar efectivamente las advertencias. Por ejemplo, en mi máquina:

export PYTHONMALLOC=malloc
valgrind python my_script.py

No produce ningún error relacionado con python.