Crash micro-reports in RHEL7

Automatic Bug Reporting Tool (ABRT) in RHEL 7.0 features additional type of lightweight bug report that can be used to report software crashes to Red Hat. These reports, called uReports, are designed to contain no potentially sensitive information, and do not require you to download potentially large amount of debugging information. They will allow Red Hat to keep track of bug occurrences while not necessarily providing enough information for our engineers to fix the bug. For that, you still may have to send a full bug report.

From RHEL 7.1 customers have the option to send authenticated uReports that contain hostname, machine-id and RHN account number. If enabled Red Hat will be able provide instant solutions to crashes.

What exactly does a uReport contain?

ABRT supports uReports for four types of crashes: crashes of C/C++ programs that result in a core dump, uncaught Python exceptions, uncaught Java exceptions and kernel oopses.

Each uReport generally contains a stack trace, or multiple stack traces in the case of multi-threaded C/C++ and Java programs. The stack trace only describes the call stack of the program at the time of the crash and does not contain contents of any variables.

Every uReport also contains identification of the operating system, versions of the RPM packages involved in the crash, and whether the program ran under a root user.

There are also items specific to each crash type:

• for C/C++ crashes, these are: path to the executable and signal delivered to the program
• for Python exceptions, there is the type of the exception (without the error message, which may contain sensitive data)
• for kernel oopses, these are: list of loaded kernel modules, list of taint flags, and full text of the kernel oops

Warning: The full text of a kernel oops might contain information like the identification of the host hardware type. You should disable the auto-reporting feature if you do not want to share this information with Red Hat.

See the Examples of uReports article for actual uReport examples.

Are the reports sent automatically?

You can turn the automatic reporting on by running abrt-auto-reporting enabled as root or by making sure that /etc/abrt/abrt.conf contains the following line:

AutoreportingEnabled = yes

From RHEL 7.1 there is an option to turn on authenticated auto-reporting using abrt-auto-reporting enabled -u <RHN user name>. This will ask for your password and save it in plain text into /etc/libreport/plugins/rhtsupport.conf. When enabled, uReports contain hostname and a machine-id (taken from systemd's /etc/machine-id). The uReport is also identified by your RHN account number. This way Red Hat is able to provide instant solutions to occurring crashes.

Where are the reports sent?

Regular uReports are sent to Red Hat's private crash report server, authenticated uReports directly to the Red Hat Customer Portal.

Can I view the reports I sent?

This is currently not possible.

What can I do to make sure the bug will be fixed?

You can use the ABRT to send a full bug report to the Customer Portal or the Bugzilla bug tracker. If you are running a graphical user interface, you can do it by running ABRT, selecting the problem, clicking the Report button and following the instructions.

If you prefer to use command-line tools you can use the abrt-cli program to send the bug report.

The full bug report needs careful inspection for sensitive data and thus cannot be completely automated. However, it usually provides more information that make it possible for Red Hat engineers to correct the problem.

Does the crash detection have an impact on system performance?

Java exceptions

In order to be able to report uncaught exceptions, the abrt-java-connector agent must register several JVMTI event callbacks and the processing inside of those callbacks have not-insignificant impact on the performance of an entire application.

If this is a concern to you, you can disable the Java uncaught exception detection by uninstalling the abrt-java-connector package.

Other problem types

The handlers for C/C++ and Python problems are only invoked on fatal program crashes and therefore should not impact the performance of normal system operation. Kernel oopses are detected by scanning log files, which should have negligible performance impact.