#118: New test proposal: Python debugability
--------------------+-------------------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: minor | Milestone:
Component: tests | Version: 1.0
Keywords: |
--------------------+-------------------------------------------------------
From Adam Williamson:
I've cut some of the context, but
basically David wants to write a test case for checking whether Python
debugging is possible as intended, and I asked exactly how he wanted it
to be used.
{{{
On Tue, 2010-01-26 at 15:30 -0500, David Malcolm wrote:
> > Can I request a test case to cover debuggability of the
Python
runtime
> > please (both in Fedora and in RHEL).
> >
> > This is in relation to:
> >
https://bugzilla.redhat.com/show_bug.cgi?id=556975
> >
https://bugzilla.redhat.com/show_bug.cgi?id=558977
> >
https://bugzilla.redhat.com/show_bug.cgi?id=557772
> >
> > as there seem to be gcc and gdb issues, which are conspiring to
make
> > python impossible to debug.
> >
> >
> > The requirement is: within "gdb python", I must be able to select
a
> > PyEval_EvalFrameEx frame, and have the following work:
> > (gdb) print co
> > (gdb) print f
> >
> > rather that have <variable optimized out>
> >
> > so that I can do this:
> > (gdb) print (char*)(((PyStringObject*)co->co_name)->ob_sval)
> > to get the function name
> >
> > (gdb) print (char*)(((PyStringObject*)co->co_filename)->ob_sval)
> > to get the source filename
> >
> > and
> >
> > (gdb) print f->f_lineno
> > to get the approximate source line number.
> >
> > If the above isn't working, it becomes extremely hard to
meaningfully
> > debug any issues that arise inside Python.
This is probably scriptable, and a good candidate for AutoQA and
foe
RHTS.
}}}
--
Ticket URL: <
https://fedorahosted.org/autoqa/ticket/118>
AutoQA <
http://autoqa.fedorahosted.org>
Automated QA project