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?
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
