Abrt (was Re: Most buggy packages)

[Jiri Moskovcak]

On 02/19/2013 01:13 PM, David Malcolm wrote:
> On Tue, 2013-02-19 at 11:33 +0100, Miroslav Suchý wrote:
>> I was curious what is the most buggy [1] package in Fedora and I made
>> this chart:
>>
>> http://tinyurl.com/bx6brjh
>>
>> Click on "Total" and you get it sorted from most buggy to least buggy.
>> (I do not know if this sort flag can be made part of URL).
>>
>> Lazy to click? Here is Top 10:.
>>
>> Component  	NEW	ASSIGNED	TOTAL
>> Package Review	943	384	1327
>> kernel		884	118	1002
>> gnome-shell	619	15	634
>> anaconda	463	85	548
>> xorg-x11-server	439	15	454
>> yum		335	14	349
>> python		334	5	339
>> tracker		294	8	302
>> control-center	205	1	206
>> rhythmbox	202	1	203
>
> How many of these bugs have "abrt" in the subject?
> For Python's NEW bugs its about 2/3rds of them.
>
> abrt consistently gets the component wrong for Python bugs; initially
> any time a Python script segfaulted (thus crashing /usr/bin/python) abrt
> assigned the component as python.  For a while this was fixed, and it
> filed the component as whatever the bottom of the stack was.  But it
> regressed a while back.
>

- Sorry to hear that, I can't find a bz ticket for this issue, so that 
might be reason why it's not fixed yet, so I created one in our 
upstream: https://github.com/abrt/abrt/issues/609 and started working on 
it (new update should be out asap)

> I have a script that automates some of the workload of reassigning the
> component back to where the bug really is, but it currently requires
> some manual intervention:
> http://fedorapeople.org/cgit/dmalcolm/public_git/triage.git
> so inevitably I don't run it on every bug that comes in every day, and
> so I gradually get behind.
>
> Of course, architecturally, this is completely bogus - it's insane for
> bugs to be filed in bugzilla for segfaults and for me to be running a
> script when I get emails in my inbox to try to triage them.
> What we really should be doing is have abrt report crashes to a
> dedicated crash-reporting db (I believe the retrace server is this), and
> the crash-reporting db should load the coredump with the right debuginfo
> packages, and triage accordingly.
>
> In particular, I think the right way for retrace server to triage is to
> run Python code embedded within gdb.  There are a ton of little
> heuristics about such code:
> http://fedorapeople.org/cgit/dmalcolm/public_git/triage.git/tree/rules.py
> that need to run server-side.  In particular, for scripting languages,
> it's most useful to be able to extract the script-level backtrace from
> the C-level stack (i.e. "what was the Python code doing?")
> http://fedorapeople.org/cgit/dmalcolm/public_git/triage.git/tree/backtrace.py#n46
> has some smarts for doing this purely from a textual backtrace from gdb,
> but running code like this directly within gdb on the retrace server
> would likely get better results.
>

- sure thing that's exactly what is the "ABRT server" (aka faf) meant for
- please check your inbox I sent you email (a month ago) about 
integration of those scripts to the server-side analysis and we can 
start working on it


Regards,
--Jirka

>
>> And most overloaded assignee is:
>>     http://tinyurl.com/a39bawg
>> again click on "Total".
>>
>> Lazy to click? Here is Top 10:
>>
>> Assignee		NEW	ASSIGNED	TOTAL
>> nobody at fedoraproject.org	871	37	908
>> kernel-maint at redhat.com	680	63	743
>> xgl-maint at redhat.com	704	14	718
>> bnocera at redhat.com	635	20	655
>> otaylor at redhat.com	637	15	652
>> tbzatek at redhat.com	476	20	496
>> rstrode at redhat.com	460	28	488
>> mclasen at redhat.com	398	25	423
>> dakingun at gmail.com	373	9	382
>> dmalcolm at redhat.com	358	7	365
>>
>>
>> [1] I know there can be plenty of metrics, I just used this one.
>
>