[ 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:
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: 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
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
----------------------------------------------------------------------
>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 21:29
Message:
Logged In: YES
user_id=33168
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
Message:
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.
----------------------------------------------------------------------
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