[ZODB-Dev] Latest news: core dump with small change to POSException.py
Jeremy Hylton
jeremy@zope.com
Tue, 25 Sep 2001 18:22:53 -0400 (EDT)
>>>>> "GW" == Greg Ward <gward@mems-exchange.org> writes:
GW> On 25 September 2001, Jeremy Hylton said:
>> for PyEval_EvalCodeEx grab the co->co_name value (*) for
>> eval_frame grab the f->f_lineno value
>>
>> That information for the top frame or two may help.
GW> OK, here it is:
GW> (gdb) frame 0
GW> #0 eval_frame (f=0x810f984) at Python/ceval.c:726
GW> 726 Py_DECREF(v); (gdb) p f->f_lineno $1 = 397 (gdb) frame 1
GW> #1 0x8075400 in PyEval_EvalCodeEx (co=0x81934c0,
GW> #globals=0x8198144,
GW> locals=0x0, args=0x8198964, argcount=5, kws=0x8198978,
GW> kwcount=1, defs=0x81ae800, defcount=2, closure=0x0) at
GW> Python/ceval.c:2542
GW> 2542 retval = eval_frame(f); (gdb) p ((PyStringObject
GW> *)co->co_name)->ob_sval $3 = "t"
GW> Assuming testConflict.py is the file, line 397 is an "except"
GW> clause. I don't see any identifier 't' in that code.
Close, but not quite. The identifier starts with 't', but that isn't
the full identifier. You'll need to look at
p ((PyStringObject *)co->co_name)->ob_sval[0]
p ((PyStringObject *)co->co_name)->ob_sval[1]
p ((PyStringObject *)co->co_name)->ob_sval[2]
p ((PyStringObject *)co->co_name)->ob_sval[3]
etc.
until you see the full identifier.
Jeremy