[ python-Bugs-985708 ] valgrind/memcheck alert: Python 2.3.4 Objects/obmalloc.c

SourceForge.net noreply at sourceforge.net
Thu Jul 8 03:29:17 CEST 2004

Bugs item #985708, was opened at 2004-07-06 00:11
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Neal Norwitz (nnorwitz)
Summary: valgrind/memcheck alert: Python 2.3.4 Objects/obmalloc.c

Initial Comment:
While trying to debug a segmentation fault I 
discovered to my great
surpise that Python 2.3.4 is not valgrind/memcheck 
clean. I observed
the same problem with three different versions of 
valgrind under
three different Linux versions:

    Python 2.3.4 (#1, May 29 2004, 02:54:59) 
    [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-
113)] on linux2

    Python 2.3.4 (#1, Jul  5 2004, 19:51:02) 
    [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on 

    Python 2.3.4 (#7, Jul  5 2004, 20:34:14) 
    [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-20)] 
on linux2

In the following I'll report results obtained under 
Red Hat Linux 3.2.3
with valgrind-2.1.1. The valgrind source code is 
available at this


In my experience valgrind is a very reliable tool.

A am using Python-2.3.4.tgz as downloaded today 
from python.org.
After a fresh ./configure --prefix=/var/tmp/py234 
and make
executing the command

  valgrind --tool=memcheck ./python

produces this output:

==32282== Memcheck, a memory error detector for 
==32282== Copyright (C) 2002-2004, and GNU 
GPL'd, by Julian Seward.
==32282== Using valgrind-2.1.1, a program 
supervision framework for x86-linux.
==32282== Copyright (C) 2000-2004, and GNU 
GPL'd, by Julian Seward.
==32282== For more details, rerun with: -v
==32282== Conditional jump or move depends on 
uninitialised value(s)
==32282==    at 0x807AE88: PyObject_Free 
==32282==    by 0x8074B81: dictresize 
==32282==    by 0x8074D61: PyDict_SetItem 
==32282==    by 0x8082E01: 
PyString_InternInPlace (stringobject.c:4140)

Plus a few hundred lines more that are not shown. 
These are lines
710 and 711 of obmalloc.c:

        pool = POOL_ADDR(p);
        if (ADDRESS_IN_RANGE(p, pool->arenaindex)) 

ADDRESS_IN_RANGE is a complicated macro. 
Therefore I've inserted
the following print statemnt:

        pool = POOL_ADDR(p);
        if (pool->arenaindex == 0) printf("HELLO\n");
        if (ADDRESS_IN_RANGE(p, pool->arenaindex)) 

With this valgrind still points to line 711, i.e. 
apparently the
problem is that pool->arenaindex is not initialized. 
However, the
output shows a large number of HELLO, suggesting 
that the uninitialized
value is 0 by coincidence.

Is this something to worry about? Or is this a rare 
case of valgrind
being mistaken? (It would be the first such case for 



>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 21:29

Logged In: YES 

Tim, was there anything else you wanted me to do for this? 
Thanks for proffredding the valgrind README.


Comment By: Tim Peters (tim_one)
Date: 2004-07-06 00:23

Logged In: YES 

Neal, where did you document the 
Py_USING_MEMORY_DEBUGGER gimmick?  I didn't find 
anything about it NEWS, or in Misc/SpecialBuilds.txt.

Ralf, yes, ADDRESS_IN_RANGE reads uninitialized memory.  
This is an intentional extreme speed hack, and won't change.  
Neal checked things in to current CVS Python to support 
telling valgrind to shut up about it, but I don't know how to 
use that ... ah, OK, in current CVS Python, read 


You can respond by visiting: 

More information about the Python-bugs-list mailing list