Это нормально, что запуск python под valgrind показывает много ошибок с памятью?

Я попытался отладить сбой памяти в моем расширении Python C и попытался запустить скрипт под valgrind. Я обнаружил, что в выводе valgrind слишком много "шума", даже если я выполнил простую команду как:

valgrind python -c ""

Вывод Valgrind полон повторяющейся информации, например:

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

Это нормальное поведение? Если это так, то, возможно, valgrind не подходит для отладки ошибок памяти в Python?


person bialix    schedule 05.10.2009    source источник


Ответы (6)


Вы можете попробовать использовать файл подавления, который поставляется с исходный код python

Также неплохо было бы прочитать Python Valgrind README!

person Nick Craig-Wood    schedule 05.10.2009
comment
В качестве примечания высокого уровня: в целом Valgrind нуждается в некоторой помощи с настраиваемыми распределителями, поскольку он не может понять поведение настраиваемого распределителя, как это могла бы стандартная реализация. - person Falaina; 05.10.2009
comment
Итак, если я правильно прочитал readme valgrind, я действительно не смогу использовать valgrind для отладки расширения python c без компиляции моего собственного дистрибутива python ?! - person black_puppydog; 05.08.2016

Это обычное дело в любой большой системе. Для явного подавления предупреждений можно использовать систему подавления Valgrind что вам неинтересно.

person unwind    schedule 05.10.2009

По ссылкам, предоставленным Ником, я смог найти некоторые обновления на README.valgrind. Одним словом, для Python> 3.6 вы можете установить переменную среды PYTHONMALLOC=malloc, чтобы эффективно отключить предупреждения. Например, на моей машине:

export PYTHONMALLOC=malloc
valgrind python my_script.py

не вызывает ошибок, связанных с python.

person liwt31    schedule 17.11.2018

Самый правильный вариант - сообщить Valgrind, что он должен перехватывать функции распределения Python. Вы должны исправить valgrind / coregrind / m_replacemalloc / vg_replace_malloc.c, добавив новые перехватчики для PyObject_Malloc, PyObject_Free, PyObject_Realloc, например:

ALLOC_or_NULL(NONE,                  PyObject_Malloc,      malloc);

(обратите внимание, что soname для функций распределения пользователей должно быть NONE)

person Glider    schedule 18.12.2009

Да, это типично. В больших системах память часто остается не освобожденной, и это нормально, если она постоянна и не пропорциональна истории работы системы. Интерпретатор Python попадает в эту категорию.

Возможно, вы можете отфильтровать вывод valgrind, чтобы сосредоточиться только на выделениях, сделанных в вашем расширении C?

person Ned Batchelder    schedule 05.10.2009

Я нашел еще один вариант. У Джеймса Хенстриджа есть собственная сборка python, которая может определять тот факт, что python работает под valgrind, и в этом случае распределитель pymalloc отключен, а PyObject_Malloc / PyObject_Free переходит в обычный malloc / free, который valgrind знает, как отслеживать.

Пакет доступен здесь: https://launchpad.net/~jamesh/+archive/python

person bialix    schedule 02.12.2009