Barry and I have both seen a debug version of Python
fail when we exit an interpreter after using pdb.  The
failure in both cases is reported in line 400 of
frameobject.c on the first iteration of the loop that
frees the stack.  The object being decrefed has already
been freed.

I don't know how to reliably provoke the problem, but I
do have a core file.

(gdb) where
#0  0x42029331 in kill () from /lib/i686/libc.so.6
#1  0x40033bdb in raise () from /lib/i686/libpthread.so.0
#2  0x4202a8c2 in abort () from /lib/i686/libc.so.6
#3  0x080e4aac in Py_AtExit (func=0xbfffba80) at
../Python/pythonrun.c:1369
#4  0x0807d767 in _Py_NegativeRefcount (
    fname=0x8125884 "../Objects/frameobject.c",
lineno=400, op=0x4078e114)
    at ../Objects/object.c:104
#5  0x08105e26 in frame_dealloc (f=0x81c0d24) at
../Objects/frameobject.c:400
#6  0x08081723 in _Py_Dealloc (op=0x81c0d24) at
../Objects/object.c:1976
#7  0x080e7522 in tb_dealloc (tb=0x40788b74) at
../Python/traceback.c:41
#8  0x08081723 in _Py_Dealloc (op=0x40788b74) at
../Objects/object.c:1976
#9  0x080e74ca in tb_dealloc (tb=0x40788cb4) at
../Python/traceback.c:40
#10 0x08081723 in _Py_Dealloc (op=0x40788cb4) at
../Objects/object.c:1976
#11 0x080e74ca in tb_dealloc (tb=0x40788cf4) at
../Python/traceback.c:40
#12 0x08081723 in _Py_Dealloc (op=0x40788cf4) at
../Objects/object.c:1976
#13 0x0807a197 in PyDict_DelItem (op=0x4007f994,
key=0x4081a5e8)
    at ../Objects/dictobject.c:571
#14 0x0807d4de in PyDict_DelItemString (v=0x4007f994, 
    key=0x8119ab0 "exc_traceback") at
../Objects/dictobject.c:1973
#15 0x080e5382 in PySys_SetObject (name=0x8119ab0
"exc_traceback", v=0x0)
    at ../Python/sysmodule.c:65
#16 0x080bfa91 in reset_exc_info (tstate=0x4007c028) at
../Python/ceval.c:2750
#17 0x080be907 in eval_frame (f=0x81c058c) at
../Python/ceval.c:2367
#18 0x080bf4d3 in PyEval_EvalCodeEx (co=0x4015c9c8,
globals=0x401f2d54, 
    locals=0x0, args=0x40773898, argcount=2, kws=0x0,
kwcount=0, 
    defs=0x40162ef0, defcount=1, closure=0x0) at
../Python/ceval.c:2602
#19 0x08108877 in function_call (func=0x4016a444,
arg=0x40773884, kw=0x0)
    at ../Objects/funcobject.c:501
#20 0x0805bf67 in PyObject_Call (func=0x4016a444,
arg=0x40773884, kw=0x0)
    at ../Objects/abstract.c:1755
#21 0x08063fd6 in instancemethod_call (func=0x4016a444,
arg=0x40773884, kw=0x0)
    at ../Objects/classobject.c:2411
#22 0x0805bf67 in PyObject_Call (func=0x40730074,
arg=0x40769f4c, kw=0x0)
    at ../Objects/abstract.c:1755
#23 0x0809b4f9 in slot_tp_call (self=0x406d2d54,
args=0x40769f4c, kwds=0x0)
    at ../Objects/typeobject.c:4357
#24 0x0805bf67 in PyObject_Call (func=0x406d2d54,
arg=0x40769f4c, kw=0x0)
    at ../Objects/abstract.c:1755
#25 0x080c186d in do_call (func=0x406d2d54,
pp_stack=0xbfffc344, na=1, nk=0)
    at ../Python/ceval.c:3565
#26 0x080c1115 in call_function (pp_stack=0xbfffc344,
oparg=1)
    at ../Python/ceval.c:3381
#27 0x080bd63f in eval_frame (f=0x8178f64) at
../Python/ceval.c:2055
#28 0x080bf4d3 in PyEval_EvalCodeEx (co=0x4015f810,
globals=0x401f2d54, 
    locals=0x0, args=0x40773240, argcount=2, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2602

Logged In: YES 
user_id=6380

This is going to be tricky unless we find a reliable way to
reproduce it. :-(

Logged In: YES 
user_id=6380

I hav seen segfaults like this too, but never bothered to
debug them. :-(

The bug report is about 5 years old and probably outdated. Please open a
new one if you see the bug again.