É normal que a execução de python sob mostra valgrind muitos erros com a memória?
-
19-09-2019 - |
Pergunta
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?
Solução
Você pode tentar usar o arquivo de supressão que vem com a fonte python
Python Valgrind README é uma boa idéia também !
Outras dicas
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.
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
)
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.
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?
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