[Python-Dev] Python under valgrind

Gustavo Carneiro gjcarneiro at gmail.com
Fri Nov 28 13:54:38 CET 2008


2008/11/28 Hrvoje Niksic <hrvoje.niksic at avl.com>

> 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?


I can't answer your question directly, but I can tell you that whenever I
have to debug memory problems with python extensions is usually use my own
python compiled with --with-pydebug --without-pymalloc.  It really helps
with valgrind.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20081128/13408172/attachment.htm>


More information about the Python-Dev mailing list