Это нормально, что запуск 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?
7 ответов
Вы можете попробовать использовать файл подавления, который поставляется с исходным кодом Python
Чтение Python Valgrind README тоже хорошая идея!
Следуя ссылкам, предоставленным Ником, я смог найти некоторые обновления на README.valgrind. Одним словом, для Python > 3.6 вы можете установить PYTHONMALLOC=malloc переменная окружения для эффективного отключения предупреждений. Например, в моей машине:
export PYTHONMALLOC=malloc
valgrind python my_script.py
не выдает никаких ошибок, связанных с питоном.
Это довольно часто встречается в любой крупной системе. Вы можете использовать систему подавления Valgrind для явного подавления предупреждений, которые вас не интересуют.
Самый правильный вариант - сообщить 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)
Есть еще один вариант, который я нашел. У Джеймса Хенстриджа есть пользовательская сборка python, которая может обнаружить тот факт, что python работает под valgrind, и в этом случае распределитель pymalloc отключен, при этом PyObject_Malloc/PyObject_Free проходит через обычный malloc/free, который valgrind знает, как отследить.
Пакет доступен здесь: https://launchpad.net/~jamesh/+archive/python
Это вполне НОРМАЛЬНО. Если вы хотите более эффективно использовать Valgrind и обнаруживать еще больше утечек памяти, вам нужно настроить python --without-pymalloc. https://svn.python.org/projects/python/trunk/Misc/README.valgrind
Да, это типично. Большие системы часто оставляют память неосвобожденной, что хорошо, если она постоянна и не пропорциональна истории работы системы. Интерпретатор Python попадает в эту категорию.
Возможно, вы можете отфильтровать вывод valgrind, чтобы сосредоточиться только на выделениях, сделанных в вашем расширении C?