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
    valgrind-1.9.5

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

    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
    valgrind-2.1.1

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
location:

    http://valgrind.kde.org/

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 
x86-linux.
==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==
==32282== Conditional jump or move depends on 
uninitialised value(s)
==32282==    at 0x807AE88: PyObject_Free 
(obmalloc.c:711)
==32282==    by 0x8074B81: dictresize 
(dictobject.c:477)
==32282==    by 0x8074D61: PyDict_SetItem 
(dictobject.c:550)
==32282==    by 0x8082E01: 
PyString_InternInPlace (stringobject.c:4140)
==32282==

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 
me.)

Thanks,
        Ralf

Logged In: YES 
user_id=31435

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 
Misc/README.valgrind.

Logged In: YES 
user_id=33168

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

Logged In: YES 
user_id=31435

No, I meant to close it as Fixed -- and did that now.  I 
assume it wasn't backported to the 2.3 line (and that's fine 
by me).