[Python-bugs-list] [Bug #113779] test_gc coredump on Alpha

[noreply@sourceforge.net]

Bug #113779, was updated on 2000-Sep-06 21:44
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 3
Summary: test_gc coredump on Alpha

Details: Configured --with-cycle-gc --with-sigfpe

gc: collectable <list 0x12043d158>
gc: collectable <dictionary 0x12043d1d8>
gc: collectable <list 0x12043d158>
gc: collectable <tuple 0x12043d198>
gc: collectable <class 0x12043d218>
gc: collectable <dictionary 0x12043d278>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d2c8>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d328>
gc: collectable <instance method 0x12043d378>
gc: collectable <B instance at 0x12043d6b8>
gc: collectable <dictionary 0x12043d6f8>
gc: uncollectable <dictionary 0x12043d5f8>
gc: uncollectable <A instance at 0x12043d158>
Segmentation fault (core dumped)

gdb reports:

Core was generated by `./python -tt Lib/test/regrtest.py -l -v test_gc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2.1...done.
Reading symbols from /lib/libutil.so.1.1...done.
Reading symbols from /lib/libm.so.6.1...done.
Reading symbols from /lib/libc.so.6.1...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
168             if (!PyList_Check(op)) {
(gdb) where
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
#1  0x120085fac in handle_finalizers (finalizers=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:312
#2  0x1200862d8 in collect (young=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:438
#3  0x120086704 in gc_collect (self=0x100000000, args=0x12043d158)
    at ./gcmodule.c:588
#4  0x120018ef0 in call_builtin (func=0x1, arg=0x12039e258, kw=0x0)
    at ceval.c:2628
#5  0x120018d30 in PyEval_CallObjectWithKeywords (func=0x1204377c0, 
    arg=0x12039e258, kw=0x0) at ceval.c:2596
#6  0x12001713c in eval_code2 (co=0x12043b890, globals=0x12043d158, 
    locals=0x120370488, args=0xffffffffffffffff, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1929
#7  0x120016cc4 in eval_code2 (co=0x12043c400, globals=0x12043d158, 
    locals=0x120370488, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
...

(gdb) print op
$1 = (PyObject *) 0x100000000
(gdb) print newitem
$2 = (PyObject *) 0x12043d158



Follow-Ups:

Date: 2000-Sep-06 21:49
By: none

Comment:
Note that without -l to regrtest it does NOT dump core,
and completes correctly.

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

Date: 2000-Sep-07 08:23
By: bwarsaw

Comment:
It could just be a bug in the debug printing of collected objects.  The -l switch for the regrtest simply adds a call to gc.set_debug(gc.DEBUG_LEAK) before the rest of the tests get going.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:02
By: none

Comment:
By the way, the original post was made by tomh@po.crl.go.jp,
who can test a fix.  However, he's out of town until 9/14.

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

Date: 2000-Sep-14 11:38
By: nascheme

Comment:
The output from "print *op" and "print *newitem" would have been useful.  The 0x100000000 pointer looks funny.  It is a really pointer or NULL or what?  If its not a real pointer then somehow the uncollectable garbage list was corrupted or was not initialized. 
-------------------------------------------------------

Date: 2000-Sep-22 10:35
By: gvanrossum

Comment:
Several fixes have been checked in to the GC code. Could the original (anonymous :-( ) submitter -- or someone else with access to an Alpha -- check out the current CVS tree and see if the problem is fixed?
-------------------------------------------------------

Date: 2000-Sep-22 15:39
By: nascheme

Comment:
Found it.  PyArg_ParseTuple(args, "l:set_debug", &debug) when debug is
declared as an int.  This one was tricky to track down.  "set watch" is your friend even though software watchpoints suck.  Thanks Compaq for your test-drive program.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113779&group_id=5470