FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-25-2010, 10:35 PM
David Malcolm
 
Default Status of Fedora 13 Featu EasierPythonDebugging

https://fedoraproject.org/wiki/Features/EasierPythonDebugging
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)
(gdb) bt
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:
https://admin.fedoraproject.org/updates/python-2.6.4-24.fc13
https://admin.fedoraproject.org/updates/python3-3.1.2-3.fc13
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" parameter
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:
https://bugzilla.redhat.com/show_bug.cgi?id=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
bugs: http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers

Which tracker should this be in?

Dave

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-26-2010, 07:00 PM
Adam Williamson
 
Default Status of Fedora 13 Featu EasierPythonDebugging

On Thu, 2010-03-25 at 19:35 -0400, David Malcolm wrote:

> (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" parameter
> 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:
> https://bugzilla.redhat.com/show_bug.cgi?id=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
> bugs: http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
>
> Which tracker should this be in?

This is a tricky question. We haven't really answered the question yet
of whether bugs impacting the implementation of accepted features for a
release should be treated as release blockers; so far we've worked
strictly on the basis of the release criteria, which are more about
whether the release meets certain targets for quality, more or less
regardless of the deeper functionality of the software it contains.

I'm not sure it's a super-simple question to answer. The classic
question to ask about a proposed blocker bug is 'would we delay the
release if this was the only bug in it?', and that's a tough question to
answer in the context of something which is essentially an RFE, and one
which can be fixed post-release without really causing anyone any
significant pain.

So the short answer is that at present, we - by 'we' I mean the
qa/releng folks who mostly do the release shepherding process - wouldn't
consider this bug to be a candidate for F13Beta or F13Blocker. You could
put it on F13Target, but the Target tracker has its own problems at
present, the short version of which is that basically everyone ignores
it. So go ahead, but it likely will have little practical impact...

There's obviously space to improve the process here. There may well be
space for a dedicated tracker for bugs affecting the implementation of
planned features. What various groups - qa, releng, devel - would *do*
with such a tracker is also an open question.

Ideas?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 04:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org