This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Error in obmalloc.
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: nnorwitz Nosy List: cmouse, mwh, nnorwitz
Priority: normal Keywords:

Created on 2004-01-21 19:39 by cmouse, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
python.pid6399.log cmouse, 2004-01-21 19:39 Log of python's errors.
Messages (7)
msg19761 - (view) Author: Aki Tossavainen (cmouse) Date: 2004-01-21 19:39
There appears to be some sort of problem with 
obmalloc.c's PyObject_Free() function.

From valgrind's output:
# more python.pid6399
==6399== Memcheck, a.k.a. Valgrind, a memory error 
detector for x86-linux.
==6399== Copyright (C) 2002-2003, and GNU GPL'd, by 
Julian Seward.
==6399== Using valgrind-2.0.0, a program supervision 
framework for x86-linux.
==6399== Copyright (C) 2000-2003, and GNU GPL'd, by 
Julian Seward.
==6399==
==6399== My PID = 6399, parent PID = 19903.  Prog 
and args are:
==6399==    python
==6399== Estimated CPU clock rate is 1100 MHz
==6399== For more details, rerun with: -v
==6399==
==6399== Conditional jump or move depends on 
uninitialised value(s)
==6399==    at 0x4A9BDE74: PyObject_Free 
(obmalloc.c:711)
==6399==    by 0x4A9B8198: dictresize 
(dictobject.c:477)
==6399==    by 0x4A9C1B90: PyString_InternInPlace 
(stringobject.c:4139)
==6399==    by 0x4A9C1C42: PyString_InternFromString 
(stringobject.c:4169)
==6399==    by 0x4A9CBE27: add_operators 
(typeobject.c:5200)
==6399==    by 0x4A9C999C: PyType_Ready 
(typeobject.c:3147)
==6399==    by 0x4A9C9DAF: PyType_Ready 
(typeobject.c:3115)
==6399==    by 0x4A9BCFCF: _Py_ReadyTypes 
(object.c:1961)
==6399==    by 0x4AA1C78B: Py_Initialize 
(pythonrun.c:172)
==6399==    by 0x4AA252AB: Py_Main (main.c:370)
==6399==    by 0x8048708: main (ccpython.cc:10)
==6399==    by 0x4ABA391D: __libc_start_main (libc-
start.c:152)
==6399==    by 0x8048630: (within /usr/bin/python)

==6399== Use of uninitialised value of size 4
==6399==    at 0x4A9BDE7E: PyObject_Free 
(obmalloc.c:711)
==6399==    by 0x4A9B8198: dictresize 
(dictobject.c:477)
==6399==    by 0x4A9C1B90: PyString_InternInPlace 
(stringobject.c:4139)
==6399==    by 0x4A9C1C42: PyString_InternFromString 
(stringobject.c:4169)
==6399==    by 0x4A9CBE27: add_operators 
(typeobject.c:5200)
==6399==    by 0x4A9C999C: PyType_Ready 
(typeobject.c:3147)
==6399==    by 0x4A9C9DAF: PyType_Ready 
(typeobject.c:3115)
==6399==    by 0x4A9BCFCF: _Py_ReadyTypes 
(object.c:1961)
==6399==    by 0x4AA1C78B: Py_Initialize 
(pythonrun.c:172)
==6399==    by 0x4AA252AB: Py_Main (main.c:370)
==6399==    by 0x8048708: main (ccpython.cc:10)
==6399==    by 0x4ABA391D: __libc_start_main (libc-
start.c:152)
==6399==    by 0x8048630: (within /usr/bin/python)

==6399== Invalid read of size 4
==6399==    at 0x4A9BDE6F: PyObject_Free 
(obmalloc.c:711)
==6399==    by 0x4A9D3564: pmerge 
(typeobject.c:1177)
==6399==    by 0x4A9CCEFC: mro_implementation 
(typeobject.c:1248)
==6399==    by 0x4A9C85A7: mro_internal 
(typeobject.c:1272)
==6399==    by 0x4A9C9A3A: PyType_Ready 
(typeobject.c:3163)
==6399==    by 0x4A9BD031: _Py_ReadyTypes 
(object.c:1976)
==6399==    by 0x4AA1C78B: Py_Initialize 
(pythonrun.c:172)
==6399==    by 0x4AA252AB: Py_Main (main.c:370)
==6399==    by 0x8048708: main (ccpython.cc:10)
==6399==    by 0x4ABA391D: __libc_start_main (libc-
start.c:152)
==6399==    by 0x8048630: (within /usr/bin/python)
==6399==    Address 0x4BEAC010 is not stack'd, 
malloc'd or free'd

and so on and so on. You can find valgrind from 
http://valgrind.kde.org/

These lines show up in the log when I do

valgrind --num-callers=20 --logfile=python python

My version of Python is 2.3.2. You can find the original 
logfile attached. All I did was start python and hit 'ctrl+d'
msg19762 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2004-01-22 11:01
Logged In: YES 
user_id=6656

Well, yeah, pymalloc engages in behaviour that is not in strict 
conformance with the ANSI C standard.  We knew this already.  As 
yet, no platform has been reported as having problems with this, 
though.

If you want to use valgrind to look for real problems, reading

http://mail.python.org/pipermail/python-dev/2003-July/
036740.html

and the containing thread may be of interest (or you could just 
turn pymalloc off at configure time).
msg19763 - (view) Author: Aki Tossavainen (cmouse) Date: 2004-01-22 15:53
Logged In: YES 
user_id=198027

Could you put into somewhere some suppression file you can 
use with valgrind... so that no patching is required. If it's not 
a real problem then it could be just suppressed.
msg19764 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2004-01-22 16:06
Logged In: YES 
user_id=6656

Hmm, the patch in the mail i referred you too never seems to 
have got checked in, despite Tim telling Neal to :-)

Neal?

(can't do anything now, SF developer CVS is down)

msg19765 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2004-01-22 16:11
Logged In: YES 
user_id=33168

Heh, I recently found I didn't check in my valgrind patch. 
I don't know what happened.  I will do this when CVS comes
back.  Unfortunately, it seems SF has been having CVS
problems (again) for a while now.
msg19766 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2004-06-06 19:59
Logged In: YES 
user_id=33168

Checked in some fixes to improve use of valgrind.  Most
importantly, you should read Misc/README.valgrind

 * Objects/obmalloc.c 2.52 and 2.53
 * Misc/README.valgrind 1.1
 * Misc/valgrind-python.supp 1.1
msg19767 - (view) Author: Aki Tossavainen (cmouse) Date: 2004-06-07 06:13
Logged In: YES 
user_id=198027

Nice. Thank you very much
History
Date User Action Args
2022-04-11 14:56:02adminsetgithub: 39845
2004-01-21 19:39:30cmousecreate