[ python-Bugs-985708 ] valgrind/memcheck alert: Python 2.3.4
Objects/obmalloc.c
SourceForge.net
noreply at sourceforge.net
Tue Jul 6 06:11:32 CEST 2004
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
More information about the Python-bugs-list
mailing list