[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