Created attachment 1472878 [details]
/var/spool/abrt/ccpp-2018-08-02-15:21:39.339717-2341/event_log (truncated at beginning by abrt)

Description of problem: Automatic reporting of application crashes by 
abrt is horribly inefficient.  In important cases it is a factor of 30 slower than necessary for SIGSEGV in a large application such as thunderbird.

I suffered the crash and watched the automatic reporting by abrt of https://bugzilla.redhat.com/show_bug.cgi?id=1611852: [abrt] thunderbird: nsProfileLock::FatalSignalHandler(): thunderbird killed by SIGSEGV.  abrt took over half an hour, including over 20 minutes using nearly 100% of 1 CPU, to report the crash.  It should have taken around 1 minute.  event_log is attached.

86 debuginfo files required fetching, expanding to over 1GB of disk space.  Two debuginfo were gigantic: thunderbird and one other.  abrt truncated the beginning of the event_log, but I watched System tools > Monitor and /usr/bin/top.  Unpacking debuginfo for thunderbird took over 60 seconds of at least 98% CPU.  abrt did nothing else while expanding, not even downloading the other files.  In contrast, it is easy for one process to download a list of .debuginfo.rpm files, writing into a pipe the name of each resulting file as it is received.  The second process reads filenames from the pipe and expands each .debuginfo.rpm in turn.  This two-stage pipeline achieves maximal overlap, and the savings is likely to be significant when there is at least one large debuginfo.rpm.

Then the backtrace.  There were 5 separate attempts, setting the depth limit on number of frames to 1024, 512, 256, 128, and 64.  Each attempt except the last took 4 minutes of 100% CPU.  The first 4 attempts were discarded because the output was too long at 267161 bytes (1/4 MB).  By looking at the final, accepted backtrace https://bugzilla.redhat.com/attachment.cgi?id=1472829 it can be seen that using the actual number of discovered frames (15 + 1) is a much better metric than the size in bytes.  A line that begins with '#' is an easy heuristic for a discovered frame.

Even the final accepted backtrace took nearly 2 minutes to compute only 16 frames.  Yes, the map of program counter to line number is intricate; but process it once to produce a table that can be searched quickly.  And pipeline the construction of the table with decompression of the file.

Version-Release number of selected component (if applicable):
abrt-2.10.10-1.fc28.x86_64


How reproducible: did not try


Steps to Reproduce:
1. wait for thunderbird to die from SIGSEGV
2. wait for abrt to report the crash in thunderbird
3.

Actual results: abrt takes over half an hour to report the crash.


Expected results: abrt takes one minute to report the crash.


Additional info: 3.3 GHz Intel Core-i5 with 32BG DDR3.