[Python-Dev] Python under valgrind

[Hrvoje Niksic]

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?