(original) (raw)

A friend pointed out that running python under valgrind (simply "valgrind python") produces a lot of "invalid read" errors.  Reading up on Misc/README.valgrind only seems to describe why "uninitialized reads" should occur, not invalid ones.  For example:

$ valgrind python
\[... lots of output ...\]
\==31428== Invalid read of size 4
\==31428==    at 0x808EBDF: PyObject\_Free (in /usr/bin/python2.5)
\==31428==    by 0x810DD0A: (within /usr/bin/python2.5)
\==31428==    by 0x810DD34: PyNode\_Free (in /usr/bin/python2.5)
\==31428==    by 0x80EDAD9: PyRun\_InteractiveOneFlags (in /usr/bin/python2.5)
\==31428==    by 0x80EDDB7: PyRun\_InteractiveLoopFlags (in /usr/bin/python2.5)
\==31428==    by 0x80EE515: PyRun\_AnyFileExFlags (in /usr/bin/python2.5)
\==31428==    by 0x80595E6: Py\_Main (in /usr/bin/python2.5)
\==31428==    by 0x8058961: main (in /usr/bin/python2.5)
\==31428==  Address 0x43bf010 is 3,112 bytes inside a block of size 6,016 free'd
\==31428==    at 0x4024B4A: free (vg\_replace\_malloc.c:323)
\==31428==    by 0x8059C07: (within /usr/bin/python2.5)
\==31428==    by 0x80EDAA5: PyRun\_InteractiveOneFlags (in /usr/bin/python2.5)
...

valgrind claims that Python reads 4 bytes inside a block on which free() has already been called.  Is valgrind wrong, or is Python really doing that?  Googling revealed previous reports of this, normally answered by a reference to README.valgrind.  But README.valgrind justifies reading from ununitialized memory, which doesn't help me understand how reading from the middle of a block of freed memory (more precisely, memory on which the libc free() has already been called) would be okay.

I suppose valgrind could be confused by PyFree's pool address validation that intentionally reads the memory just before the allocated block, and incorrectly attributes it to a previously allocated (and hence freed) block, but I can't prove that.  Has anyone investigated this kind of valgrind report?