هل من الطبيعي أن يؤدي تشغيل 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 ربما أداة غير مناسبة لتصحيح أخطاء الذاكرة في بيثون؟

Answer 1

يمكنك محاولة استخدام إخماد ملف هذا يأتي مع مصدر بيثون

اقرأ ال بيثون Valgrind Readme. هي فكرة جيدة أيضا!

Answer 2

هذا شائع جدا، في أي نظام فرق. يمكنك استخدام Valgrind's نظام قمع لإغلاق التحذيرات صراحة أنك غير مهتم بها.

Answer 3

الخيار الأكثر صحة هو إخبار Valgrind بأنه يجب أن يعترض وظائف تخصيص Python. يجب عليك التصحيح Valgrind / CoreGrind / m_replacemallocc / vg_replace_malloc.c إضافة اعتراضات جديدة لل pyobject_malloc، pyobject_free، pyobject_realloc، على سبيل المثال:

ALLOC_or_NULL(NONE,                  PyObject_Malloc,      malloc);

(لاحظ أن وظائف سونامي لتخصيص المستخدمين يجب أن تكون NONE)

Answer 4

الروابط التالية التي قدمها نيك كنت قادرا على العثور على بعض التحديثات readme.valgrind.. وبعد في كلمة واحدة، بالنسبة لبيثون> 3.6، يمكنك ضبط PYTHONMALLOC=malloc متغير البيئة لتعطيل التحذيرات بشكل فعال. على سبيل المثال، في جهازي:

export PYTHONMALLOC=malloc
valgrind python my_script.py

لا ينتج أي خطأ يتعلق بثثون.

Answer 5

نعم، هذا نموذجي. غالبا ما تترك الأنظمة الكبيرة الذاكرة غير محررة، وهي جيدة طالما أنها كمية ثابتة، ولا تتناسب مع تاريخ التشغيل للنظام. مترجم الثعبان يقع في هذه الفئة.

ربما يمكنك تصفية إخراج Valgrind للتركيز فقط على التخصيصات الموجودة في ملحق C الخاص بك؟

Answer 6

هناك خيار آخر وجدته. يحتوي James Henstridge على بناء مخصص من Python الذي يمكنه اكتشاف حقيقة أن Python قيد التشغيل تحت Valgrind وفي هذه الحالة يتم تعطيل مخصص Pymalloc، مع Pyobject_Malloc / Pyobject_Free تمر عبر Malloc / Free، أي Valgrind يعرف كيفية تتبع.

الحزمة المتاحة هنا: https://launchpad.net/~Jamesh/+archive/Python.