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 12-09-2010, 02:51 PM
Adam Jackson
 
Default abrt wishlist

Here's some of my pet irritations with abrt. Feel free to add your own,
but please keep the gratuitous "me too"ing to a minimum.

1) The generated reports contain far too little information for library
owners. Consider this report:

https://bugzilla.redhat.com/show_bug.cgi?id=658013

I get the EVRs for the kernel, and for the executable that happened to
be running, but not for any of the libraries in between, even though the
report very carefully tells me exactly which DSOs are loaded and where
they are in memory.

2) I really dislike that "local trace generation" and "retrace server"
are discussed as though they're the only options. If nothing else, for
many non-trivial apps where abrt is potentially of the most use the core
you're uploading can easily be hundreds of megabytes; that's not really
better than downloading hundreds of megabytes. A network debuginfo
service [1] would approach this problem in a completely different way,
by letting the client download exactly as much debuginfo as it needs.

3) Reporting to bugzilla is a mistake.

4) Reporting to bugzilla without being able to scrape the bz username
and password out of the firefox credential store is just cruel.

[1] - http://git.fedorahosted.org/git/?p=littlebottom.git;a=summary

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 03:10 PM
David Malcolm
 
Default abrt wishlist

On Thu, 2010-12-09 at 10:51 -0500, Adam Jackson wrote:
> Here's some of my pet irritations with abrt. Feel free to add your own,
> but please keep the gratuitous "me too"ing to a minimum.
>
> 1) The generated reports contain far too little information for library
> owners. Consider this report:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=658013
>
> I get the EVRs for the kernel, and for the executable that happened to
> be running, but not for any of the libraries in between, even though the
> report very carefully tells me exactly which DSOs are loaded and where
> they are in memory.
Gratuitous me too!

But more seriously, I filed this a while back as:
https://bugzilla.redhat.com/show_bug.cgi?id=555205
"RFE: include "rpm -qf" output for all memory-mapped DSOs"

This would be a great boon to things like python where you can have an
arbitrary amount of DSOs mapped into your process, from pretty much the
whole of the distribution (which is both a good and a bad thing; would
love to sandbox python modules, but that's an unsolved problem, AIUI).

> 2) I really dislike that "local trace generation" and "retrace server"
> are discussed as though they're the only options. If nothing else, for
> many non-trivial apps where abrt is potentially of the most use the core
> you're uploading can easily be hundreds of megabytes; that's not really
> better than downloading hundreds of megabytes. A network debuginfo
> service [1] would approach this problem in a completely different way,
> by letting the client download exactly as much debuginfo as it needs.

Another gratuitous me too, see:
https://fedoraproject.org/wiki/Talk:Features/RetraceServer

I'm wondering why the network debuginfo service couldn't be simply wired
up to Koji's rpm via readonly NFS and scrape debugingo rpms on demand.

> 3) Reporting to bugzilla is a mistake.

FWIW, I'll mention again my ABRT triage scripts; they help me keep sane
whre dealing with incoming crash reports:
http://fedorapeople.org/gitweb?p=dmalcolm/public_git/triage.git;a=tree

(The heuristics there are targetting python crash reports, since that
what I get)

> 4) Reporting to bugzilla without being able to scrape the bz username
> and password out of the firefox credential store is just cruel.

Seems like this should in bugzilla.



Hope this is helpful
Dave

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 03:20 PM
Jiri Moskovcak
 
Default abrt wishlist

Gathering the RFEs at: https://fedorahosted.org/abrt/wiki/Wishlist

On 12/09/2010 04:51 PM, Adam Jackson wrote:
> Here's some of my pet irritations with abrt. Feel free to add your own,
> but please keep the gratuitous "me too"ing to a minimum.
>
> 1) The generated reports contain far too little information for library
> owners. Consider this report:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=658013
>
> I get the EVRs for the kernel, and for the executable that happened to
> be running, but not for any of the libraries in between, even though the
> report very carefully tells me exactly which DSOs are loaded and where
> they are in memory.
>

- added as "add NVRs for loaded libraries"

> 2) I really dislike that "local trace generation" and "retrace server"
> are discussed as though they're the only options. If nothing else, for
> many non-trivial apps where abrt is potentially of the most use the core
> you're uploading can easily be hundreds of megabytes; that's not really
> better than downloading hundreds of megabytes. A network debuginfo
> service [1] would approach this problem in a completely different way,
> by letting the client download exactly as much debuginfo as it needs.
>

I mentioned the debuginfofs many times in ABRT flames, there was however
a problem with our debug tools making it unusable, because one had to
read the whole debuginfo file from the server and few other problems so
that's why the retrace server idea came up. but this should fixed in the
current tools so theoretically nothing prevents us from reviving it..
once this is done ABRT can easily use it...

> 3) Reporting to bugzilla is a mistake.

- added as: "don't report directly to bz"

> 4) Reporting to bugzilla without being able to scrape the bz username
> and password out of the firefox credential store is just cruel.
>

- added as: "share bz credential with other apps"
- not sure if we can share the credentials with firefox, but we can
share it with apps that store it in the gnome-keyring (which ff doesn't)

> [1] - http://git.fedorahosted.org/git/?p=littlebottom.git;a=summary
>
> - ajax
>

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 04:10 PM
Adam Williamson
 
Default abrt wishlist

On Thu, 2010-12-09 at 17:20 +0100, Jiri Moskovcak wrote:

> > 4) Reporting to bugzilla without being able to scrape the bz username
> > and password out of the firefox credential store is just cruel.

> - added as: "share bz credential with other apps"
> - not sure if we can share the credentials with firefox, but we can
> share it with apps that store it in the gnome-keyring (which ff doesn't)

Could we turn this into 'use the same reporting system as selinux'? It's
absurd that they use different ones, you should merge them.
--
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
 
Old 12-09-2010, 04:21 PM
Michael Cronenworth
 
Default abrt wishlist

Adam Williamson wrote:
> Could we turn this into 'use the same reporting system as selinux'? It's
> absurd that they use different ones, you should merge them.

Something like: *cough* Event Log *cough*
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 04:31 PM
Jiri Moskovcak
 
Default abrt wishlist

On 12/09/2010 06:10 PM, Adam Williamson wrote:
> On Thu, 2010-12-09 at 17:20 +0100, Jiri Moskovcak wrote:
>
>>> 4) Reporting to bugzilla without being able to scrape the bz username
>>> and password out of the firefox credential store is just cruel.
>
>> - added as: "share bz credential with other apps"
>> - not sure if we can share the credentials with firefox, but we can
>> share it with apps that store it in the gnome-keyring (which ff doesn't)
>
> Could we turn this into 'use the same reporting system as selinux'? It's
> absurd that they use different ones, you should merge them.

selinux uses the report package as a reporting back-end and we're
planning (and working on..) to obsolete the report package by splitting
ABRT reporting backed into a separate library so then ABRT and selinux
will use the same reporting backend and thus they will store the
settings in one place..

J.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 05:46 PM
Adam Jackson
 
Default abrt wishlist

On Thu, 2010-12-09 at 17:20 +0100, Jiri Moskovcak wrote:

> > 2) I really dislike that "local trace generation" and "retrace server"
> > are discussed as though they're the only options. If nothing else, for
> > many non-trivial apps where abrt is potentially of the most use the core
> > you're uploading can easily be hundreds of megabytes; that's not really
> > better than downloading hundreds of megabytes. A network debuginfo
> > service [1] would approach this problem in a completely different way,
> > by letting the client download exactly as much debuginfo as it needs.
> >
>
> I mentioned the debuginfofs many times in ABRT flames, there was however
> a problem with our debug tools making it unusable, because one had to
> read the whole debuginfo file from the server and few other problems so
> that's why the retrace server idea came up. but this should fixed in the
> current tools so theoretically nothing prevents us from reviving it..
> once this is done ABRT can easily use it...

I have trouble following what you're saying here. At what point does
one need to "read the whole debuginfo file"?

- ajax

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-09-2010, 06:39 PM
Jiri Moskovcak
 
Default abrt wishlist

On 12/09/2010 07:46 PM, Adam Jackson wrote:
> On Thu, 2010-12-09 at 17:20 +0100, Jiri Moskovcak wrote:
>
>>> 2) I really dislike that "local trace generation" and "retrace server"
>>> are discussed as though they're the only options. If nothing else, for
>>> many non-trivial apps where abrt is potentially of the most use the core
>>> you're uploading can easily be hundreds of megabytes; that's not really
>>> better than downloading hundreds of megabytes. A network debuginfo
>>> service [1] would approach this problem in a completely different way,
>>> by letting the client download exactly as much debuginfo as it needs.
>>>
>>
>> I mentioned the debuginfofs many times in ABRT flames, there was however
>> a problem with our debug tools making it unusable, because one had to
>> read the whole debuginfo file from the server and few other problems so
>> that's why the retrace server idea came up. but this should fixed in the
>> current tools so theoretically nothing prevents us from reviving it..
>> once this is done ABRT can easily use it...
>
> I have trouble following what you're saying here. At what point does
> one need to "read the whole debuginfo file"?
>

I'm referring to this:
https://fedorahosted.org/pipermail/crash-catcher/2010-September/000965.html


Jirka

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-10-2010, 02:24 AM
Jan Kratochvil
 
Default abrt wishlist

On Thu, 09 Dec 2010 20:39:24 +0100, Jiri Moskovcak wrote:
> On 12/09/2010 07:46 PM, Adam Jackson wrote:
> > I have trouble following what you're saying here. At what point does
> > one need to "read the whole debuginfo file"?
>
> I'm referring to this:
> https://fedorahosted.org/pipermail/crash-catcher/2010-September/000965.html

GDB on client side would need something like readonly NFS-like service to load
the .debug files byte-wise. And this NFS-like service network protocol must
be signed by Fedora project like the current rpms are.

Then the fast operation of GDB on the client depends on these known issues:

* http://fedoraproject.org/wiki/Features/GdbIndex which is now present in F14
updated packages (but it still was not present in F14 GA packages).

* Recheck THe .debug files reading via .gdb_index is really optimal for the
network protocol.

* Fixing GDB to not ever touch .debug files for libraries not going to be
used in the specific backtrace at all.


Regards,
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-10-2010, 07:24 AM
Michal Hlavinka
 
Default abrt wishlist

Adding my whishlist

1) /etc/abrt/conf.d/ directory - like httpd ones. So I can drop there configuration for my packages. For example when dovecot crashes, I'd like to see doveconf -n output

2) better notification for crashes. I have one application that crashes when I'm ending desktop session, but because abrt-gui is not running at that time (or it's just terminated when it shows up) I'm not notified about that crash and when I log in next time, nothing happens.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 03:35 AM.

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