is currently marked as 95%, but a better answer is "it's complicated".
I've done all I can for now to finish it, and it does provide some
useful improvements, but it's being heavily impacted by a bug outside of
my expertise (see (b) below).
I've been testing the feature, building out a test suite, and sending
upstream as http://bugs.python.org/issue8032
The torture test for this feature that I've been using is to run "yum
update", then hit CTRL-Z as it's running, then:
[david@brick ~]$ gdb attach $(pidof -x yum)
and see what you can see.
There are two outstanding bugs with the feature:
(a) the attach-to-yum testcase found a nasty issue: when there are
cycles in the graph of python object references, my pretty-print code
would take gdb into an infinite recursion. I've fixed this (and various
other bugs) in v4 of the hooks so that with v4 of the hooks it seems to
be robust. I've built python/python3 with v4; the relevant updates are:
and ought to be installable on a f13 host with:
su -c 'yum --enablerepo=updates-testing update python python3'
so this is in "testing", though not in the tree yet.
(b) the critically important frame information within the heart of the
bytecode excution loop ought to tell us what code we're running, but is
showing up in gdb as "optimized out". (specifically, the "f"
to function PyEval_EvalFrameEx).
Unfortunately, this greatly reduces the effectiveness of the feature
(it's still somewhat useful without this, but the feature page would
need a significant rewrite if this doesn't get fixed).
This looks like a regression of rhbz:556975:
I don't know if this is a gcc/gdb/python issue.
I've reopened this bug. I haven't yet added it to any of the tracker
Which tracker should this be in?