[Python-Dev] valgrind

Neal Norwitz nnorwitz at gmail.com
Tue Nov 7 08:02:22 CET 2006

On 11/6/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Herman Geza schrieb:
> > Here python reads from an already-freed memory area, right?
> It looks like it, yes. Of course, it could be a flaw in valgrind, too.
> To find out, one would have to understand what the memory block is,
> and what part of PyObject_Free accesses it.

I'm a bit confused.  I ran with valgrind ./python -c pass which
returns 23 invalid read problems (some are the same chunk of memory).
This is with 2.5 (more or less).  Valgrind 3.2.1 on amd64.  Every
address ended with 0x5...020.  That seems odd.  I looked through the
valgrind bug reports and didn't see anything.  The first problem
reported was:

Invalid read of size 4
   at 0x44FA06: Py_ADDRESS_IN_RANGE (obmalloc.c:1741)
   by 0x44E225: PyObject_Free (obmalloc.c:920)
   by 0x44EB90: _PyObject_DebugFree (obmalloc.c:1361)
   by 0x444A28: dictresize (dictobject.c:546)
   by 0x444D5B: PyDict_SetItem (dictobject.c:655)
   by 0x462533: PyString_InternInPlace (stringobject.c:4920)
   by 0x448450: PyDict_SetItemString (dictobject.c:2120)
   by 0x4C240A: PyModule_AddObject (modsupport.c:615)
   by 0x428B00: _PyExc_Init (exceptions.c:2117)
   by 0x4C449A: Py_InitializeEx (pythonrun.c:225)
   by 0x4C4827: Py_Initialize (pythonrun.c:315)
   by 0x41270A: Py_Main (main.c:449)
 Address 0x52AE020 is 4,392 bytes inside a block of size 5,544 free'd
   at 0x4A1A828: free (vg_replace_malloc.c:233)
   by 0x5071635: qsort (in /lib/libc-2.3.5.so)
   by 0x474E4B: init_slotdefs (typeobject.c:5368)
   by 0x47522E: add_operators (typeobject.c:5511)
   by 0x46E3A1: PyType_Ready (typeobject.c:3209)
   by 0x46E2D4: PyType_Ready (typeobject.c:3173)
   by 0x44D13E: _Py_ReadyTypes (object.c:1864)
   by 0x4C4362: Py_InitializeEx (pythonrun.c:183)
   by 0x4C4827: Py_Initialize (pythonrun.c:315)
   by 0x41270A: Py_Main (main.c:449)
   by 0x411CD2: main (python.c:23)

Note that the free is inside qsort.  The memory freed under qsort
should definitely not be the bases which we allocated under
PyType_Ready.  I'll file a bug report with valgrind to help determine
if this is a problem in Python or valgrind.

One other thing that is weird is that the complaint is about 4 bytes
which should not be possible.  All pointers should be 8 bytes AFAIK
since this is amd64.

I also ran this on x86.  There were 32 errors and all of their
addresses were 0x4...010.


More information about the Python-Dev mailing list