python2.0 dumps core in gc_list_remove

[ephedra]

BPO	220983
Nosy	@gvanrossum, @nascheme

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/nascheme'
closed_at = <Date 2000-12-17.06:17:56.000>
created_at = <Date 2000-11-01.09:17:38.000>
labels = ['interpreter-core']
title = 'python2.0 dumps core in gc_list_remove'
updated_at = <Date 2000-12-17.06:17:56.000>
user = 'https://bugs.python.org/ephedra'

bugs.python.org fields:

activity = <Date 2000-12-17.06:17:56.000>
actor = 'nascheme'
assignee = 'nascheme'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2000-11-01.09:17:38.000>
creator = 'ephedra'
dependencies = []
files = []
hgrepos = []
issue_num = 220983
keywords = []
message_count = 5.0
messages = ['2271', '2272', '2273', '2274', '2275']
nosy_count = 4.0
nosy_names = ['gvanrossum', 'jhylton', 'nascheme', 'ephedra']
pr_nums = []
priority = 'low'
resolution = None
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue220983'
versions = []

[ephedra]

Source: downloaded from http://www.python.org
OS: freebsd 4.1
Compilation options: default
(does not occur when compiled with --without-cycle-gc)
Observed while: running Zope2-cvs.

I have not tested this on other operating systems, but it seems reproducible, if intermittent on freebsd. I will keep the binary and the corefile in case further information is needed.

some information extracted with gdb:

#0 0x80a8ffb in gc_list_remove (node=0x89eab40) at ./gcmodule.c:88
---Type <return> to continue, or q <return> to quit---
88 node->gc_next->gc_prev = node->gc_prev;
(gdb) p node
$1 = (struct _gc_head *) 0x89eab40
(gdb) p node->gc_next
$2 = (struct _gc_head *) 0x0
#0 0x80a8ffb in gc_list_remove (node=0x89eab40) at ./gcmodule.c:88
#1 0x80a9ac3 in _PyGC_Remove (op=0x89eab40) at ./gcmodule.c:523
#2 0x807e01d in instance_dealloc (inst=0x89eab4c) at classobject.c:552
#3 0x808ea46 in insertdict (mp=0x89f004c, key=0x89e3ba8, hash=134733596,
value=0x8064d13) at dictobject.c:343
#4 0x808ee01 in PyDict_SetItem (op=0x89f004c, key=0x89e3ba8, value=0x807df1c)
at dictobject.c:477
#5 0x2836e33c in subclass_simple_setattro (self=0x89ea900, name=0x8835760,
v=0x89ead6c) at ./../Components/ExtensionClass/ExtensionClass.c:2174
#6 0x283914cc in _setattro (self=0x89ea900, oname=0x8835760, v=0x89ead6c,
setattrf=0x2836e2cc <subclass_simple_setattro>) at ./cPersistence.c:661
#7 0x283915d0 in Per_setattro (self=0x89ea900, oname=0x8835760, v=0x89ead6c)
at ./cPersistence.c:701
#8 0x80926c5 in PyObject_SetAttr (v=0x89eab40, name=0x89e3ba8,
value=0x807df1c) at object.c:767
#9 0x283ae5df in Wrapper_setattro (self=0x8856f70, oname=0x8835760,
v=0x89ead6c) at ./../Components/ExtensionClass/Acquisition.c:600

...

(gdb) up
#1 0x80a9ac3 in _PyGC_Remove (op=0x89eab40) at ./gcmodule.c:523
523 gc_list_remove(g);
(gdb) p *g
$4 = {gc_next = 0xc, gc_prev = 0x80db600, gc_refs = 7}
(gdb) up
#2 0x807e01d in instance_dealloc (inst=0x89eab4c) at classobject.c:552
552 PyObject_GC_Fini(inst);
(gdb) p *inst
$6 = {ob_refcnt = 0, ob_type = 0x80d89e0, in_class = 0x88a790c,
in_dict = 0x89eeccc}
(gdb) p *inst->ob_type
$7 = {ob_refcnt = 10, ob_type = 0x80db740, ob_size = 0,
tp_name = 0x80cb646 "instance", tp_basicsize = 28, tp_itemsize = 0,
tp_dealloc = 0x807df1c <instance_dealloc>, tp_print = 0, tp_getattr = 0,
tp_setattr = 0, tp_compare = 0x807e860 <instance_compare>,
tp_repr = 0x807e690 <instance_repr>, tp_as_number = 0x80d8940,
tp_as_sequence = 0x80d8900, tp_as_mapping = 0x80d88ec,
tp_hash = 0x807e93c <instance_hash>, tp_call = 0, tp_str = 0,
tp_getattro = 0x807e278 <instance_getattr>,
tp_setattro = 0x807e388 <instance_setattr>, tp_as_buffer = 0x0,
tp_flags = 15, tp_doc = 0x0, tp_traverse = 0x807ead4 <instance_traverse>,
tp_clear = 0, tp_xxx7 = 0, tp_xxx8 = 0}
(gdb) p *inst->in_class
$8 = {ob_refcnt = 4, ob_type = 0x80d8880, cl_bases = 0x80fbcac,
cl_dict = 0x88a794c, cl_name = 0x88a54c0, cl_getattr = 0x0,
cl_setattr = 0x0, cl_delattr = 0x0}

[jhylton]

From a cursory glance, I would guess this is a problem with the extension classes used by Zope, not with the garbage collector.

[nascheme]

Tobias, is this core dump still occuring? If it is, can you
provide some details on how to reproduce it?

[gvanrossum]

Neil, this is the only complaint about this. It may well be a user error.
Try direct mail to the submitter; if he doesn't reply or doesn't provide new information, you can close the bug report.

[nascheme]

I'm closing this bug. The core dump is likely caused by one
of Zope's extension modules. The stack trace doesn't tell
me much. The list of container objects has obviously been
corrupted but its unlikely that the functions on the stack
are responsible. I'll wait for more people to complain
before digging deeper.