É normal que a execução de python sob mostra valgrind muitos erros com a memória?

Question

Eu tentei acidente de memória de depuração na minha extensão Python C e tentou correr roteiro sob valgrind. Eu encontrei há muito "ruído" na saída valgrind, mesmo que eu tenha de comando correu simples como:

valgrind python -c ""

saída Valgrind cheio de informações repetidas assim:

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

É um comportamento normal? Se sim, então valgrind talvez é uma ferramenta inadequada para a depuração de erros de memória em Python?

Answer 1

Você pode tentar usar o arquivo de supressão que vem com a fonte python

Python Valgrind README é uma boa idéia também !

Answer 2

Isso é muito comum, em qualquer sistema de largish. Você pode usar do Valgrind supressão do sistema para avisos explicitamente suprimir que você não está interessado.

Answer 3

A opção mais correta é dizer Valgrind que deveria interceptar funções de alocação do Python. Você deve corrigir valgrind / coregrind / m_replacemalloc / vg_replace_malloc.c adicionando os novos interceptores para PyObject_Malloc, PyObject_Free, PyObject_Realloc, por exemplo:.

ALLOC_or_NULL(NONE,                  PyObject_Malloc,      malloc);

(note que o soname para funções de alocação de usuários devem ser NONE)

Answer 4

seguintes links dadas por Nick eu era capaz de encontrar algumas atualizações sobre README.valgrind . Em uma palavra, para Python> 3.6, você pode definir variável de ambiente PYTHONMALLOC=malloc desativar efetivamente os avisos. Por exemplo, na minha máquina:

export PYTHONMALLOC=malloc
valgrind python my_script.py

não produz qualquer erro relacionado com python.

Answer 5

Sim, isso é típico. Grandes sistemas muitas vezes deixam un-libertado memória, que é bom, desde que seja uma quantidade constante, e não proporcional à história de funcionamento do sistema. O interpretador Python se enquadra nessa categoria.

Talvez você pode filtrar a saída valgrind se concentrar apenas em alocações feitas no seu ramal C?

Answer 6

Não há outra opção que eu encontrei. James Henstridge tem compilação personalizada de python que pode detectar o fato de que python que funciona sob valgrind e neste caso pymalloc alocador está desativado, com PyObject_Malloc / PyObject_Free passagem para malloc normais / livre, que valgrind sabe como controlar.

O pacote disponível aqui: https://launchpad.net/~jamesh/+archive/python