What's wrong with ABRT?
Originally, with stock F-12, I had received a couple of good backtraces in bugzilla. Incredibly useful. A wonderful improvement over F-11 and older.
And later? - Recently, in all the backtraces dozens of debuginfo packages are missing. :-(
On Tue, Dec 29, 2009 at 10:56 AM, Michael Schwendt mschwendt@gmail.comwrote:
Originally, with stock F-12, I had received a couple of good backtraces in bugzilla.
I can't comment on its usefulness to developers, but as a user of the thing, it's horrid. It's extremely hard to figure out what it's for, then how to use it (if only to make that red flashing light go away), and then it's quite often unreliable in delivering bug reports or making it clear that any particular crash has or has not been reported correctly. I applaud the idea behind it, but what a mess from an implementation standpoint :-(
On 12/29/2009 09:40 PM, Bryan O'Sullivan wrote:
On Tue, Dec 29, 2009 at 10:56 AM, Michael Schwendtmschwendt@gmail.comwrote:
Originally, with stock F-12, I had received a couple of good backtraces in bugzilla.
, and then it's quite often unreliable in delivering bug reports or making it clear that any particular crash has or has not been reported correctly.
Which bugs do you mean? If you're talking about kerneloops then there is no way we can show some other message then "Thenk you for submitting" as the kerneloops server doesn't return any url with reported oops.
2009/12/29 Michael Schwendt mschwendt@gmail.com:
What's wrong with ABRT?
Originally, with stock F-12, I had received a couple of good backtraces in bugzilla. Incredibly useful. A wonderful improvement over F-11 and older.
And later? - Recently, in all the backtraces dozens of debuginfo packages are missing. :-(
That's been my experience. Starting off, ABRT worked great (except for the bug where it couldn't submit any bugs), but then it stopped being able to download debuginfo packages -- no matter how often I hit "Refresh". Then that went away with an updated version and ABRT worked well again for a bit, but now it's back to not being able to download any debuginfo packages, so all traces it generates are useless. I'm not sure what caused/causes it to go wonky that way.
Unfortunately, if this goes on, I'm afraid it'll pass the "useless annoyance" barrier and most people will remove it upon install, thus negating the reason it was created in the first place.
Cheers,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Schwendt wrote:
What's wrong with ABRT?
Originally, with stock F-12, I had received a couple of good backtraces in bugzilla. Incredibly useful. A wonderful improvement over F-11 and older.
And later? - Recently, in all the backtraces dozens of debuginfo packages are missing. :-(
I agree, Most of the abrt crash bugzilla i am assigned too, have missing debuginfo packages, kind of use less for debuging. I can ask the user to install debuginfo packages and get back to me. But without that i will have to close those bzs
- -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)
GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5
2009/12/30 Kevin Kofler kevin.kofler@chello.at:
Michael Schwendt wrote:
What's wrong with ABRT?
My main beef with it is that it reports its crashes to the downstream bug tracker when really the right people to fix them are the upstream developers. KCrash/DrKonqi is much better there.
Probably because we need to determine whether the issue is Fedora-specific (packaging bug) or is also replicated in the vanilla version before we create more noise on upstream's bug tracker. Hence why kernel developers usually ask if bugs can be reproduced from Linus' tree.
Cheers
On Wed, 30 Dec 2009 22:04:59 +0100, Kevin wrote:
What's wrong with ABRT?
My main beef with it is that it reports its crashes to the downstream bug tracker when really the right people to fix them are the upstream developers. KCrash/DrKonqi is much better there.
Well, upstream would want detailed backtraces, too.
$ grep "Debuginfo absent" attachment.cgi?id=381101 | wc -l 188 $ grep "No symb" attachment.cgi?id=381101 | wc -l 64
Those 188+64 lines are half of the backtrace attachment already $ cat attachment.cgi?id=381101 | wc -l 517
| Debuginfo absent: 0011710bbf8990924b6dd2b256219d5682db6515
Instead of logging 188 missing debuginfo hashes which isn't useful, better log human-readable package EVRs. That would tell more about what package versions a reporter used.
2009/12/29 Michael Schwendt mschwendt@gmail.com:
What's wrong with ABRT?
Originally, with stock F-12, I had received a couple of good backtraces in bugzilla. Incredibly useful. A wonderful improvement over F-11 and older.
And later? - Recently, in all the backtraces dozens of debuginfo packages are missing. :-(
Locally, for the past few days, debuginfo packages have failed to install for me because I have the rpmfusion-{free,nonfree} repositories activated, and the main mirrorlist for rpmfusion seems to have gone down, so debuginfo never completes, and abrt carries on its merry way. I suspect others are seeing this.
2009/12/31 Jonathan Underwood jonathan.underwood@gmail.com:
2009/12/29 Michael Schwendt mschwendt@gmail.com:
What's wrong with ABRT?
Originally, with stock F-12, I had received a couple of good backtraces in bugzilla. Incredibly useful. A wonderful improvement over F-11 and older.
And later? - Recently, in all the backtraces dozens of debuginfo packages are missing. :-(
Locally, for the past few days, debuginfo packages have failed to install for me because I have the rpmfusion-{free,nonfree} repositories activated, and the main mirrorlist for rpmfusion seems to have gone down, so debuginfo never completes, and abrt carries on its
^^^^^^ debuginfo-install
On 12/31/2009 07:11 PM, Jonathan Underwood wrote:
2009/12/29 Michael Schwendtmschwendt@gmail.com:
What's wrong with ABRT?
Originally, with stock F-12, I had received a couple of good backtraces in bugzilla. Incredibly useful. A wonderful improvement over F-11 and older.
And later? - Recently, in all the backtraces dozens of debuginfo packages are missing. :-(
Locally, for the past few days, debuginfo packages have failed to install for me because I have the rpmfusion-{free,nonfree} repositories activated, and the main mirrorlist for rpmfusion seems to have gone down, so debuginfo never completes, and abrt carries on its merry way. I suspect others are seeing this.
ABRT 1.0.2 should fix the problems with installing the debug packages, the only problem I know about is when some of the enabled repositories is down - then the yum fails to download debuginfo even if it's in working directory and there is not much ABRT can do about this.
On Sat, 02 Jan 2010 11:53:28 +0100, Jiri wrote:
ABRT 1.0.2 should fix the problems with installing the debug packages, the only problem I know about is when some of the enabled repositories is down - then the yum fails to download debuginfo even if it's in working directory and there is not much ABRT can do about this.
One of the ABRT test-updates warned about missing debuginfo packages. If it knows that many debuginfo packages are missing and details in the backtrace are missing, too, can it try harder to warn users about not uploading incomplete backtraces? It could warn again if a user wants to delete a report in ABRT that has only been uploaded with missing details.
On Sat, 02 Jan 2010 11:53:28 +0100, Jiri Moskovcak wrote:
the only problem I know about is when some of the enabled repositories is down - then the yum fails to download debuginfo even if it's in working directory and there is not much ABRT can do about this.
Which YUM bug # is it?
Could you provide a temporary workaround supplying something like (needs some testing): --disablerepo='*' --enablerepo='fedora*' --enablerepo='updates*'
I think --skip-broken could apply also to inaccessible repositories; but that is offtopic here - for ABRT, this is a YUM issue.
Regards, Jan
On Sat, Jan 2, 2010 at 1:25 PM, Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Sat, 02 Jan 2010 11:53:28 +0100, Jiri Moskovcak wrote:
the only problem I know about is when some of the enabled repositories is down - then the yum fails to download debuginfo even if it's in working directory and there is not much ABRT can do about this.
Which YUM bug # is it?
Could you provide a temporary workaround supplying something like (needs some testing): --disablerepo='*' --enablerepo='fedora*' --enablerepo='updates*'
I think --skip-broken could apply also to inaccessible repositories; but that is offtopic here - for ABRT, this is a YUM issue.
Well this "yum issue" is by design .. reporting it does not have much sense because Seth do not want to change/fix it.
On Sat, 02 Jan 2010 13:34:47 +0100, drago01 wrote:
On Sat, Jan 2, 2010 at 1:25 PM, Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Sat, 02 Jan 2010 11:53:28 +0100, Jiri Moskovcak wrote:
the only problem I know about is when some of the enabled repositories is down - then the yum fails to download debuginfo even if it's in working directory and there is not much ABRT can do about this.
...
Well this "yum issue" is by design .. reporting it does not have much sense because Seth do not want to change/fix it.
Found this flameware at this open Bug: https://bugzilla.redhat.com/show_bug.cgi?id=528014
Regards, Jan
On Sat, 2 Jan 2010, Jan Kratochvil wrote:
On Sat, 02 Jan 2010 13:34:47 +0100, drago01 wrote:
On Sat, Jan 2, 2010 at 1:25 PM, Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Sat, 02 Jan 2010 11:53:28 +0100, Jiri Moskovcak wrote:
the only problem I know about is when some of the enabled repositories is down - then the yum fails to download debuginfo even if it's in working directory and there is not much ABRT can do about this.
...
Well this "yum issue" is by design .. reporting it does not have much sense because Seth do not want to change/fix it.
Found this flameware at this open Bug: https://bugzilla.redhat.com/show_bug.cgi?id=528014
What flames? I said no and that - if abrt wants to do otherwise they can use the yum api to do so.
How is that a flame?
-sv
On Sat, 2010-01-02 at 11:53 +0100, Jiri Moskovcak wrote: [...]
ABRT 1.0.2 should fix the problems with installing the debug packages,
Does this mean ABRT 1.0.2 installs those missing debuginfo packages automatically and also _removes_ them after the bug was committed?
I'm not really familiar with the handling of debuginfo packages maybe someone can explain that to mean. My understanding is the following: The debuginfo packages contain symbols etc. which were striped out after the build process to ensure a small binary to save memory (and as a side effect speed). When the debuginfo package of a particular binary is installed, then the symbols are loaded whenever the binary is loaded or are the symbols only considered by tools like gdb and so on?
This is crucial to me because if the debug symbols are loaded whenever the binary is loaded, then this means a performance decrease but if they are only loaded by gdb, ABRT or whatever, then this "only" means some waste of my disk space which may be negligible (if the debuginfo packages are not removed automatically).
cheers, Stefan
On Sat, 02 Jan 2010 13:39:07 +0100, Stefan Schulze Frielinghaus wrote:
When the debuginfo package of a particular binary is installed, then the symbols are loaded whenever the binary is loaded or are the symbols only considered by tools like gdb and so on?
The latter.
Moreover ABRT does not install the whole debuginfo package but only copies the needed specific .debug files out of it somewhere - as know the ABRT people.
Jan
On 01/02/2010 03:32 PM, Jan Kratochvil wrote:
On Sat, 02 Jan 2010 13:39:07 +0100, Stefan Schulze Frielinghaus wrote:
When the debuginfo package of a particular binary is installed, then the symbols are loaded whenever the binary is loaded or are the symbols only considered by tools like gdb and so on?
The latter.
Moreover ABRT does not install the whole debuginfo package but only copies the needed specific .debug files out of it somewhere - as know the ABRT people.
Jan
Exactly, we don't install it, just extract the package to /var/cache/abrt-di. ABRT doesn't remove it automatically, but it's a planned feature.
Jirka
On 3.1.2010 13:37, Jiri Moskovcak wrote:
On 01/02/2010 03:32 PM, Jan Kratochvil wrote:
On Sat, 02 Jan 2010 13:39:07 +0100, Stefan Schulze Frielinghaus wrote:
When the debuginfo package of a particular binary is installed, then the symbols are loaded whenever the binary is loaded or are the symbols only considered by tools like gdb and so on?
The latter.
Moreover ABRT does not install the whole debuginfo package but only copies the needed specific .debug files out of it somewhere - as know the ABRT people.
Jan
Exactly, we don't install it, just extract the package to /var/cache/abrt-di. ABRT doesn't remove it automatically, but it's a planned feature.
If you will indeed implement this, please let the users choose whether they want the .debug files (or whatever you extract) to be removed or kept forever. I'm really happy with the current situation and do not want to wait until ABRT downloads the debuginfo packages every time again.
Thanks, Milos
On Sun, 2010-01-03 at 13:37 +0100, Jiri Moskovcak wrote:
On 01/02/2010 03:32 PM, Jan Kratochvil wrote:
Moreover ABRT does not install the whole debuginfo package but only copies the needed specific .debug files out of it somewhere - as know the ABRT people.
Exactly, we don't install it, just extract the package to /var/cache/abrt-di. ABRT doesn't remove it automatically, but it's a planned feature.
Why do you do this?
On 01/04/2010 07:41 AM, James Antill wrote:
On Sun, 2010-01-03 at 13:37 +0100, Jiri Moskovcak wrote:
On 01/02/2010 03:32 PM, Jan Kratochvil wrote:
Moreover ABRT does not install the whole debuginfo package but only copies the needed specific .debug files out of it somewhere - as know the ABRT people.
Exactly, we don't install it, just extract the package to /var/cache/abrt-di. ABRT doesn't remove it automatically, but it's a planned feature.
Why do you do this?
We don't need root privileges and we can have multiple versions of the same debuginfo package installed.
2010/1/4 Jiri Moskovcak jmoskovc@redhat.com:
On 01/04/2010 07:41 AM, James Antill wrote:
On Sun, 2010-01-03 at 13:37 +0100, Jiri Moskovcak wrote:
On 01/02/2010 03:32 PM, Jan Kratochvil wrote:
Moreover ABRT does not install the whole debuginfo package but only copies the needed specific .debug files out of it somewhere - as know the ABRT people.
Exactly, we don't install it, just extract the package to /var/cache/abrt-di. ABRT doesn't remove it automatically, but it's a planned feature.
Why do you do this?
We don't need root privileges and we can have multiple versions of the same debuginfo package installed.
What's the benefit of having multiple versions of the same debuginfo installed when you can't have multiple versions of the same RPM installed?
On 01/02/2010 09:32 AM, Jan Kratochvil wrote:
Moreover ABRT does not install the whole debuginfo package but only copies the needed specific .debug files out of it somewhere - as know the ABRT people.
What happens if the software version N crashes, then the updates install a later version, and the ABRT tool is run afterwards? With updates coming fast and furious, this is not uncommon, and I think it leads to confusion when the old stack trace is interpreted against the debugging info from the different software version.
On Mon, 04 Jan 2010 16:40:35 +0100, Przemek Klosowski wrote:
On 01/02/2010 09:32 AM, Jan Kratochvil wrote:
Moreover ABRT does not install the whole debuginfo package but only copies the needed specific .debug files out of it somewhere - as know the ABRT people.
What happens if the software version N crashes, then the updates install a later version, and the ABRT tool is run afterwards? With updates coming fast and furious, this is not uncommon, and I think it leads to confusion when the old stack trace is interpreted against the debugging info from the different software version.
Unaware of the ABRT issue; But even with the installed debuginfo packages the problem exists: `yum update' gets the installed debuginfos out of sync https://bugzilla.redhat.com/show_bug.cgi?id=432806 There are various Bugs referenced, such as: Debug info RPMs do not "require" exact maching binary rpm https://bugzilla.redhat.com/show_bug.cgi?id=151598
Currently YUM at least updates both the main package and its debuginfo through yum-plugin-auto-update-debug-info. The problem is with all the mirrors and daily Fedora updates the main repository and the debuginfo repository are commonly off-by-one and thus the debuginfo packages still do not match.
Regards, Jan
On Tue, Dec 29, 2009 at 7:56 PM, Michael Schwendt mschwendt@gmail.com wrote:
What's wrong with ABRT?
Originally, with stock F-12, I had received a couple of good backtraces in bugzilla. Incredibly useful. A wonderful improvement over F-11 and older.
And later? - Recently, in all the backtraces dozens of debuginfo packages are missing. :-(
Also some duplicate detection wouldn't hurt ... (I get new bug reports everyday just to notice that almost all of them are duplicates).
On Fri, 2010-01-01 at 16:45 +0100, drago01 wrote:
Also some duplicate detection wouldn't hurt ... (I get new bug reports everyday just to notice that almost all of them are duplicates).
abrt already does duplicate detection, but it's hardly a straightforward thing to do. Jiri and the rest of the team are always happy to work with anyone who has ideas on how to improve abrt's duplicate detection.
devel@lists.stg.fedoraproject.org