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

Question

Я пытался отладить сбой памяти в моем расширении 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?

Answer 1

Вы можете попробовать использовать suppression file, который поставляется с источником питона

Чтение Python Valgrind README это хорошая идея тоже!

Answer 2

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

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

Answer 3

Это довольно распространено в любой довольно большой системе. Вы можете использовать valgrind для suppression system явно подавить предупреждения о том, что вы не заинтересованы.

Answer 4

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

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

Answer 5

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

ALLOC_or_NULL(NONE,     PyObject_Malloc,  malloc); 

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