#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.
}}}
#118: New test proposal: Python debugability ---------------------+------------------------------------------------------ Reporter: kparal | Owner: Type: task | Status: new Priority: minor | Milestone: Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by kparal):
David, I think you are the most suited one for creating the test script (or maybe you already have one). It should be just a standalone program (in any language, we prefer Python) that is run and it returns successful or unsuccessful result.
For inclusion in AutoQA some control file and wrapper file are needed, but we can create them very easily once we have your script. Then according e.g. to its return code we can decide if the test has passed or failed and send appropriate result to [https://fedorahosted.org/pipermail/autoqa- results/ autoqa-results]. As Adam mentioned, we currently have no other way of communicating the results, but it's in our future plan. Is it enough for you, or will you wait until we have better infrastructure in place?
#118: New test proposal: Python debugability ---------------------+------------------------------------------------------ Reporter: kparal | Owner: Type: task | Status: new Priority: minor | Milestone: Future test cases Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by kparal):
* milestone: => Future test cases
autoqa-devel@lists.fedorahosted.org