[Python-Dev] Big trouble in CVS Python

[Tim Peters]

[martin@v.loewis.de]
> It crashes for me as well, in test_builtin, with the backtrace

Wow!  It took me hours to get there.  Noting that Anthony and Jeremy report
no problems, but Martin's symptom appears identical to mine:

> #0  0x40340019 in main_arena () from /lib/libc.so.6
> #1  0x080edad6 in visit_decref (op=0x8343fa4, data=0x80eda90) at
> Modules/gcmodule.c:236
> #2  0x08097a70 in tupletraverse (o=0x40351e64, visit=0x80eda90
> <visit_decref>, arg=0x0)
>     at Objects/tupleobject.c:398
> #3  0x080ed152 in collect (generation=2) at Modules/gcmodule.c:250
> #4  0x080ed764 in gc_collect (self=0x0, noargs=0x0) at
> Modules/gcmodule.c:731
> #5  0x080be763 in call_function (pp_stack=0xbfffee9c, oparg=24)
> at Python/ceval.c:3400
> #6  0x080bcb9e in eval_frame (f=0x834013c) at Python/ceval.c:2091
> #7  0x080bd685 in PyEval_EvalCodeEx (co=0x403aae60, globals=0x18,
> locals=0x0,
>     args=0x834013c, argcount=0, kws=0x82fb2dc, kwcount=0,
> defs=0x403bd470, defcount=11,
>     closure=0x0) at Python/ceval.c:2638
> #8  0x080be81e in fast_function (func=0x40351e64,
> pp_stack=0xbffff02c, n=0, na=0, nk=0)
>     at Python/ceval.c:3504
> #9  0x080be671 in call_function (pp_stack=0xbffff02c, oparg=24)
> at Python/ceval.c:3433
> #10 0x080bcb9e in eval_frame (f=0x82fb18c) at Python/ceval.c:2091
> #11 0x080bd685 in PyEval_EvalCodeEx (co=0x4045a220, globals=0x18,
> locals=0x4036279c,
>     args=0x82fb18c, argcount=0, kws=0x0, kwcount=0, defs=0x0,
> defcount=0, closure=0x0)
>     at Python/ceval.c:2638
>
> The tuple being traversed has 19 elements, of types:
>
> NoneType, int, int, int, int, int, int, int, int, int, int, int,
> int, int, int, long, int, float, <NULL>
>
> It crashes on the last tuple element, which is a garbage pointer.

Exactly the same here.  The tuple is the co_consts belonging to
test_builtin's test_range.  It's the 11th tuple of size 19 created
<wink/sigh>.  At the time compile.c's jcompile created the tuple:

		consts = PyList_AsTuple(sc.c_consts);

the last element was fine, a float with value 1.e101, from test_range's

        self.assertRaises(ValueError, range, 1e100, 1e101, 1e101)

Alas, none of that helps.  At the time of the crash, the last tuple entry
still points to the memory for that floatobject, but the memory has been
scribbled over.  The first 18 tuple elements appear still to be intact.

My suspicion that it's a gc problem has gotten weaker to the point of
thinking that's unlikely.  It looks more like gc is suffering the effects of
something else scribbling over memory it ought not to be poking.