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

[SourceForge.net]

Bugs item #985708, was opened at 2004-07-05 21:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985708&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
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
    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


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985708&group_id=5470