Implementation:

C/C++ handling:
==============

NOTE: This document describes legacy abrt-hook-cpp that was removed in favour of systemd-coredump.

We change /proc/sys/kernel/core_pattern to invoke abrtd helper to save
the coredump of the crashing app:
* helper source code:
the code responsible for this:

    #define CORE_PATTERN            "|/usr/libexec/abrt-hook-ccpp" "/var/tmp/abrt" %p %s %u"
    ofstream fOutCorePattern;
    fOutCorePattern.open(CORE_PATTERN_IFACE);
    if (fOutCorePattern.is_open())
    {
        fOutCorePattern << CORE_PATTERN << endl;
        fOutCorePattern.close();
    }

%p - pid
%s - signal
%u - uid

When a crash occurs abrt-hook-ccpp is invoked to store the coredump and some other info
read from /proc/<pid>/:

executable:
    char buf[sizeof("/proc/%u/exe") + sizeof(int)*3];
    sprintf(buf, "/proc/%u/exe", (int)pid);
    readlink(buf);

cmdline:
    char path[sizeof("/proc/%u/cmdline") + sizeof(int)*3];
    sprintf(path, "/proc/%u/cmdline", (int)pid);

Both are saved to a file named /var/tmp/abrt/ccpp-<time>-<pid>, readable
only by the owner of the crashed process:
    int fd = open(pPath, O_WRONLY | O_TRUNC | O_CREAT, 0666);
    if(fd){
        do {
            n = write(fd, buf, count);
        } while (n < 0 && errno == EINTR);
    }

When the hook is done it signals the daemon (by removing the lock file) and the
daemon processes the written info and saves some aditional information:
        analyzer        : name of the plugin used to analyze the crash (ccpp, python)
        component       : source package name
        description     : package description (will be removed soon)
        kernel          : kernel version
        release         : Fedora release string
        uid             : uid of the owner of the crashed app
        architecture    : architecture (i386, x86_64,etc)
        package         : package name
        reason          : e.g "Process was terminated by signal 11 (Segmentation fault)"
        time            : unix time of the crash

2. send dbus signal (broadcast) about new crash, this signal contains two pieces of information:
    1. uid of the app owner
    2. package name

This is all what happens when some app crashes, the next step is to process
the coredump and extract the backtrace. This is done on user demand by calling the
getReport(UUID) method, or is done automatically if configured in /etc/abrt/abrt.conf
* UUID is a unique id of the crash in the database, every user is allowed to see only
  their own crashes or kerneloops crashes.

1. processing coredump:
    a) determine if the crashed binary belongs to some installed package
    if it does then:
    b) the daemon tries to install the debuginfo by issuing by this command:

execlp("abrt-action-install-debuginfo", "abrt-action-install-debuginfo", coredump, tempdir, debuginfo_dirs, NULL);

abrt-action-install-debuginfo is a shell script using elfutils to get build-ids from a coredump and then use
"yum provides" and "yumdownloader" to determine and download the missing debuginfo packages
* script source code: https://github.com/abrt/abrt/blob/master/src/plugins/abrt-action-install-debuginfo.in
    c) Run gdb and get a backtrace from the coredump:
    - gdb is run with the same privileges as the crashed app (setregid, setreuid).
    d) The backtrace is saved to the same directory as the coredump.

Once the backtrace is processed all data from the /var/tmp/abrt/ccpp-<time>-<pid> file is sent
over dbus to the client and then the user can edit the backtrace. When the user is happy about
the report and instructs the client (gui, tui) to send the report, the client sends the data back
to the daemon calling the Report(data) method over the dbus. The actual reporting is done by
the respective plugin which is loaded in the daemon.
