(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?_

Closing it as "not a bug".