abrt / btparser

Parser and analyzer for backtraces produced by GDB

ABRT

A set of tools to help users detect and report application crashes.

About

Its main purpose is to ease the process of reporting an issue and finding a solution.

The solution in this context might be a bugzilla ticket, knowledge base article or a suggestion to update a package to a version containing a fix.

This repository is one among a suite of related projects. The following diagram summarizes the dependencies between the individual packages comprising the ABRT suite.

flowchart BT
    abrt-java-connector --> abrt
    abrt-java-connector -. build .-> satyr
    abrt:::focus --> libreport & satyr
    abrt-java-connector --> libreport
    gnome-abrt --> abrt & libreport
    reportd --> libreport
    libreport --> satyr
    retrace-server[Retrace Server] -. "optional, for<br>packages only" .-> faf
    faf["ABRT Analytics (FAF)"] --> satyr

click abrt "https://github.com/abrt/abrt" "abrt GitHub repository" _blank
click abrt-java-connector "https://github.com/abrt/abrt-java-connector" "abrt-java-connector GitHub repository" _blank
click faf "https://github.com/abrt/faf" "ABRT Analytics GitHub repository" _blank
click gnome-abrt "https://github.com/abrt/gnome-abrt" "gnome-abrt GitHub repository" _blank
click libreport "https://github.com/abrt/libreport" "libreport GitHub repository" _blank
click reportd "https://github.com/abrt/reportd" "reportd GitHub repository" _blank
click satyr "https://github.com/abrt/satyr" "satyr GitHub repository" _blank
click retrace-server "https://github.com/abrt/retrace-server" "Retrace Server GitHub repository" _blank

classDef focus stroke-width: 4

Loading

Documentation

Every ABRT program and configuration file has a man page describing it. It is also possible to read the ABRT documentation online. For contributors and developers, there are also wiki pages describing some topics to deeper technical details.

Development

• IRC Channel: #abrt on irc.libera.chat
• Mailing List
• Bug Reports and RFEs
• Contributing to ABRT
• Install and run ABRT

Running

ABRT consist of several services and many small utilities. While The utilities can be successfully run from the source directories after build, the services often uses the utilities to do actions and expect the utilities installed in the system directories. Hence to run the services, it is recommended to install ABRT first and run them as system services. The instructions how to build and install ABRT can be found in INSTALL.md

Technologies

• libreport - problem data format, reporting
• satyr - backtrace processing, micro-reports
• Python3
• GLib2
• Gtk3
• D-Bus
• SELinux
• systemd

btparser's Issues

Any two core backtraces containing only one frame are considered duplicate

To reproduce:

$ wil_segfault
$ will_python_raise

btp_parse_kerneloops() causes SIGSEGV if call trace is empty

$ cat backtrace
irq 19: nobody cared (try booting with the "irqpoll" option)
Pid: 1, comm: systemd Not tainted 3.8.3-203.fc18.i686 #1
Call Trace:

$ abrt-action-generate-core-backtrace
Segmentation fault (core dumped)

$ gdb abrt-action-generate-core-backtrace
Thread 1 (Thread 0x7ffff7fcb7c0 (LWP 16986)):
#0 btp_parse_kerneloops (text=text@entry=0x607940 "irq 19: nobody cared (try booting with the "irqpoll" option)\nPid: 1, comm: systemd Not tainted 3.8.3-203.fc18.i686 #1\nCall Trace:\n",

kernelver=kernelver@entry=0x6079e0 "3.8.3-203.fc18.i686") at core-backtrace-oops.c:253
    result = <optimized out>
    nextline = <optimized out>
    line = <optimized out>
    ip = <optimized out>
    first = 0x0
    last = 0x0
    first_frame = <optimized out>
    last_frame = <optimized out>

#1 0x000000000040145b in main (argc=1, argv=) at abrt-action-generate-core-backtrace.c:197

    space = <optimized out>
    dump_dir_name = 0x401957 "."
    program_usage_string = <optimized out>
    program_options = {{type = OPTION_BOOL, short_name = 118, long_name = 0x40195c "verbose", value = 0x602160, argh = 0x0, help = 0x401959 "Be verbose"}, {type = OPTION_STRING, short_name = 100, long_name = 
0x0, value = 0x7fffffffdaf8, argh = 0x401964 "DIR", help = 0x401968 "Problem directory"}, {type = OPTION_BOOL, short_name = 114, long_name = 0x40197a "raw", value = 0x602168, argh = 0x0, help = 
0x40197e "Do not hash fingerprints"}, {type = OPTION_END, short_name = 0, long_name = 0x0, value = 0x0, argh = 0x0, help = 0x0}}
    dd = 0x607390
    analyzer = <optimized out>
    executable = 0x6073c0 ""
    txt_backtrace = 0x607940 "irq 19: nobody cared (try booting with the \"irqpoll\" option)\nPid: 1, comm: systemd Not tainted 3.8.3-203.fc18.i686 #1\nCall Trace:\n"
    kernel = 0x6079e0 "3.8.3-203.fc18.i686"
    backtrace = <optimized out>
    formatted_backtrace = <optimized out>

Try harder when finding crashed thread in backtrace

If all threads having the top frame equal to the crashed function are same [1] it doesn't matter which one of these frames is returned as the result of the find crash thread function. Therefore it is not necessary to fail in this case.

Even more, we can always single out one of the threads but the selection must be predictable and the selection must return the same results for equal backtraces which has reordered threads. The algorithm can sort the threads and return the first one. A metrics for sorting can be thread frames count or something more sophisticated.

1: https://bugzilla.redhat.com/attachment.cgi?id=703269

btp_thread_parse_funs and functions with spaces

It seems when there is a function name with space (e.g. "QAbstractSocket::readData(char*, long long)", the reconstruction doesn't work properly and the text after space ("long long)" ends up in the library name.

Fix thread modifications in python

When a thread is modified in python (e.g. removed frames), these changes are not visible in the c code, the list of frames doesn't seem to be rebuilt from the python list.

drop identical oops frames crashes if bt suffix consits only from identical frames

Problematic koops:

WARNING: at kernel/watchdog.c:246 watchdog_overflow_callback+0x9c/0xd0()
Hardware name:@@@@@@@@@
Watchdog detected hard LOCKUP on cpu 2
Modules linked in:
Pid: 0, comm: swapper/2 Not tainted 3.8.4-202.fc18.x86_64 #1
Call Trace:
@
[] warn_slowpath_common+0x7f/0xc0
[] warn_slowpath_fmt+0x46/0x50
[] ? touch_nmi_watchdog+0x80/0x80
[] warn_slowpath_common+0x7f/0xc0
[] warn_slowpath_fmt+0x46/0x50
[] watchdog_overflow_callback+0x9c/0xd0
[] ? touch_nmi_watchdog+0x80/0x80
[] __perf_event_overflow+0x9d/0x230
[] watchdog_overflow_callback+0x9c/0xd0
[] ? x86_perf_event_set_period+0xd7/0x160
[] __perf_event_overflow+0x9d/0x230
[] perf_event_overflow+0x14/0x20
[] ? x86_perf_event_set_period+0xd7/0x160
[] intel_pmu_handle_irq+0x1ae/0x330
[] perf_event_overflow+0x14/0x20
[] intel_pmu_handle_irq+0x1ae/0x330
[] perf_event_nmi_handler+0x1d/0x20
[] perf_event_nmi_handler+0x1d/0x20
[] nmi_handle.isra.0+0x51/0x80
[] nmi_handle.isra.0+0x51/0x80
[] do_nmi+0xe0/0x350
[] do_nmi+0xe0/0x350
[] end_repeat_nmi+0x1e/0x2e
[] end_repeat_nmi+0x1e/0x2e
[] ? mwait_idle+0x91/0x1e0
[] ? mwait_idle+0x91/0x1e0
[] ? mwait_idle+0x91/0x1e0
[] ? mwait_idle+0x91/0x1e0
[] ? mwait_idle+0x91/0x1e0
[] ? mwait_idle+0x91/0x1e0
<>@
<> [] cpu_idle+0xfe/0x120
[] cpu_idle+0xfe/0x120
[] start_secondary+0x24f/0x251
[] start_secondary+0x24f/0x251