Bug 612954 - Abrt demands unneeded debuginfo
Abrt demands unneeded debuginfo
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: abrt (Show other bugs)
6.1
All Linux
low Severity medium
: rc
: ---
Assigned To: Denys Vlasenko
BaseOS QE - Apps
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-09 07:54 EDT by Lubomir Rintel
Modified: 2010-07-20 12:15 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-20 12:15:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
abrt traceback (16.46 KB, text/plain)
2010-07-09 07:54 EDT, Lubomir Rintel
no flags Details

  None (edit)
Description Lubomir Rintel 2010-07-09 07:54:51 EDT
Created attachment 430655 [details]
abrt traceback

Description of problem:

I've had crash in lyx (attaching it in full) caught abrt, which suggested it's missing 99 debuginfo packages and that I shjould install debuginfo packages. I've done debuginfo-install -y lyx then, which dragged in ~10 other packages and regenerated the report.

This, given most important packages including lyx-debuginfo itself got pulled in generated a much better tracback, which I thought could be submitted into bugzilla.

No luck -- abrt still whines about lot of missing debuginfos. Please note that it provided no good suggestion how to deal with this.

I therefore fired gdb, let it suggest which packages to install. ABRT was still not happy -- libicudata did not contain debugging information (bug #612946) and thus the traceback was still considered incomplete.

I'm not sure which of these really counts as abrt but here's what was problematic to me:

1.) ABRT not correctly suggesting how to install debuginfo
2.) debuginfo package possibly lacking dependencies (this is probably not the case; libraries could be ldopen()ed and rpm has no way to find out what really gets exec-mapped)
3.) ABRT possibly demanding debuginfos that were not needed for usable stack trace
4.) All debuginfo files with required build-id available should be enough for considering a bug report complete. A file missing a debugging information but having a matching build-id is most likely a packaging bug not related to the problem reported.

Version-Release number of selected component (if applicable):

abrt-1.1.4-1.el6.i686
Comment 3 Denys Vlasenko 2010-07-14 06:57:34 EDT
(In reply to comment #0)
> I've had crash in lyx (attaching it in full) caught abrt, which suggested it's
> missing 99 debuginfo packages and that I shjould install debuginfo packages.
> I've done debuginfo-install -y lyx then, which dragged in ~10 other packages
> and regenerated the report.
> 
> This, given most important packages including lyx-debuginfo itself got pulled
> in generated a much better tracback, which I thought could be submitted into
> bugzilla.
> 
> No luck -- abrt still whines about lot of missing debuginfos. Please note that
> it provided no good suggestion how to deal with this.
> 
> I therefore fired gdb, let it suggest which packages to install. ABRT was still
> not happy -- libicudata did not contain debugging information (bug #612946) and
> thus the traceback was still considered incomplete.

> I'm not sure which of these really counts as abrt but here's what was
> problematic to me:
> 
> 1.) ABRT not correctly suggesting how to install debuginfo

Did it say this?

"Reporting disabled because the backtrace is unusable.
Please try to install debuginfo manually using the command:
debuginfo-install PACKAGE_NAME"

> 2.) debuginfo package possibly lacking dependencies (this is probably not the
> case; libraries could be ldopen()ed and rpm has no way to find out what really
> gets exec-mapped)

True, we might suggest running something like "yum install /usr/lib/debug/.build-id/0b/5e4ef892c7fbdc818f602aafa72a5dd41b1d61.debug /usr/lib/debug/.build-id/0d/923d3e23cc76b13b886bd5f40f0108b5c7f96b.debug ... ... ..." which will catch that; but the command will be HUGE and nasty, users will be confused.

> 3.) ABRT possibly demanding debuginfos that were not needed for usable stack
> trace

That's really a hard problem

> 4.) All debuginfo files with required build-id available should be enough for
> considering a bug report complete. A file missing a debugging information but
> having a matching build-id is most likely a packaging bug not related to the
> problem reported.

abrt never considers missing debuginfo a problem. It looks at the trace itself - does it have function names? source file names and line numbers? etc...

Looking at your trace:

Thread 1 (Thread 8570):
#0  __kernel_vsyscall () at arch/x86/vdso/vdso32/int80.S:16
No locals.
#1  0x00911d71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        resultvar = <value optimized out>
        resultvar = <value optimized out>
        pid = 10940404
        selftid = 8570
#2  0x0091364a in abort () at abort.c:92
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0xbf907194, sa_sigaction = 
    0xbf907194}, sa_mask = {__val = {134520508, 3213914504, 2918996, 0, 
    3079483456, 1, 0, 1, 2918648, 12, 45, 3079508696, 0, 0, 1, 381, 
    3079486144, 0, 3213914576, 9387856, 3213914504, 3213914516, 2916292, 
    3213914384, 2918648, 0, 2830170, 134632069, 268435456, 3213921484, 0, 
    16384}}, sa_flags = 0, sa_restorer = 0}
        sigs = {__val = {32, 0 <repeats 31 times>}}
#3  0x0810dcbc in lyx::error_handler (err_sig=11) at LyX.cpp:634
        handling_error = 1
#4  <signal handler called>
No locals.
#5  0x00000000 in ?? ()
No symbol table info available.
#6  0x00000000 in ?? ()
No symbol table info available.


I am in agreement with abrt that the trace is unusable. It misses the crucial info - _where signal 11 happened?_
Comment 4 Denys Vlasenko 2010-07-20 12:15:09 EDT
Closing it as "not a bug".

Note You need to log in before you can comment on or make changes to this bug.