 |
Python & Valgrind & CRiSP | Sunday, 11 October 2015 |
Been adding a native python interface to CRiSP, and needed to run
valgrind on my code. Alas, Python itself seems to be polluted with
many undefined memory read scenarios (this is python2.7). A simple
python script, when run under valgrind gives rise to errors like:
==17795== Invalid read of size 4 ==17795== at 0x4A30B1: ??? (in /usr/bin/python2.7) ==17795== by 0x4E05A5: ??? (in /usr/bin/python2.7) ==17795== by 0x4C5BB1: ??? (in /usr/bin/python2.7) ==17795== by 0x4B422E: ??? (in /usr/bin/python2.7) ==17795== by 0x4B3DFA: ??? (in /usr/bin/python2.7) ==17795== by 0x4B3642: ??? (in /usr/bin/python2.7) ==17795== by 0x4B6755: ??? (in /usr/bin/python2.7) ==17795== by 0x4D437A: PyEval_CallObjectWithKeywords (in /usr/bin/python2.7) ==17795== by 0x4CF3B0: PyEval_EvalFrameEx (in /usr/bin/python2.7) ==17795== by 0x4CB6B0: PyEval_EvalCodeEx (in /usr/bin/python2.7) ==17795== by 0x4CAF55: PyEval_EvalCode (in /usr/bin/python2.7) ==17795== by 0x4C97BB: PyImport_ExecCodeModuleEx (in /usr/bin/python2.7) ==17795== Address 0x6046020 is 34,480 bytes inside a block of size 36,521 free'd ==17795== at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==17795== by 0x4C6033: PyMarshal_ReadLastObjectFromFile (in /usr/bin/python2.7) ==17795== by 0x4C5F6D: ??? (in /usr/bin/python2.7) ==17795== by 0x4C5B4B: ??? (in /usr/bin/python2.7) ==17795== by 0x4B422E: ??? (in /usr/bin/python2.7) ==17795== by 0x4B3DFA: ??? (in /usr/bin/python2.7) ==17795== by 0x4B3642: ??? (in /usr/bin/python2.7) ==17795== by 0x4B6755: ??? (in /usr/bin/python2.7) ==17795== by 0x4D437A: PyEval_CallObjectWithKeywords (in /usr/bin/python2.7) ==17795== by 0x4CF3B0: PyEval_EvalFrameEx (in /usr/bin/python2.7) ==17795== by 0x4CB6B0: PyEval_EvalCodeEx (in /usr/bin/python2.7) ==17795== by 0x4CAF55: PyEval_EvalCode (in /usr/bin/python2.7)
I havent looked at the python internals to see what and how dangerous this is.