abrt-action-analyze-c

Calculate and save the UUID for the current working directory

$ abrt-action-analyze-c

$ abrt-action-analyze-c -d [path/to/directory]

$ abrt-action-analyze-c -v

abrt-action-analyze-c [OPTIONS] [DIRECTORY]

-d, --dir DIRECTORY
    Specifies the problem directory to operate on. If not provided, the current working directory is used.

-o, --output-dir DIRECTORY
    Writes analysis output to the specified directory instead of the problem directory. This is typically used internally by ABRT.

-u, --user
    Analyzes the crash for the current user's session.

--not-user
    Analyzes the crash for the entire system, not just the user session (default behavior for system-wide ABRT instances).

-v, --verbose
    Increases the verbosity of the command's output.

-y, --yes
    Assumes "yes" to all interactive questions, if any, allowing non-interactive operation.

-h, --help
    Displays a help message and exits.

abrt-action-analyze-c is a specialized plugin within the Automatic Bug Reporting Tool (ABRT) suite, designed to analyze crashes and issues originating from C and C++ applications. When a C/C++ program crashes, ABRT collects relevant data, such as core dumps, executables, and backtraces, into a "problem directory". This command is then invoked, typically by ABRT itself, to process this collected data. It leverages gdb (GNU Debugger) to perform a deep analysis of the coredump or backtrace. The primary goal is to extract critical information about the crash, including the exact function where the crash occurred, the full stack trace, the involved executable, and the related component. This analysis results in various variables being added to the problem directory's metadata, such as reason, backtrace, executable, component, and kerneloops (if applicable). This information is crucial for ABRT to categorize, deduplicate, and eventually report the bug effectively. It requires the problem directory to contain at least a coredump (or coredump.gz) or a backtrace file, along with the executable file.

For effective analysis, especially when analyzing core dumps, the system needs to have the corresponding debugging symbols (debuginfo packages) installed for the crashing application and its libraries. Without debuginfo, stack traces might be incomplete or show only hexadecimal addresses, making analysis less useful. The command relies heavily on the presence of specific files (coredump, executable, backtrace) within the designated problem directory. It also requires gdb (GNU Debugger) to be installed and accessible on the system.

The command operates on a "problem directory", which is a directory created by ABRT containing all collected data related to a specific crash event. For abrt-action-analyze-c to function optimally, this directory typically must contain at least one of the following: a coredump file (or coredump.gz), or a backtrace file. Additionally, the executable file of the crashed program is crucial for proper symbol resolution and analysis.

This action is part of the second stage of the ABRT workflow: analysis. After ABRT collects crash data into a problem directory (the collection stage), various abrt-action-analyze-* plugins are invoked to process the data. abrt-action-analyze-c specifically handles C/C++ application crashes, adding crucial metadata. This analyzed information then aids ABRT in the reporting stage, where the categorized crash data can be sent to bug trackers or developers.

ABRT (Automatic Bug Reporting Tool) was developed by Red Hat to streamline the process of collecting and reporting software crashes and other issues on Linux systems, particularly Fedora and Red Hat Enterprise Linux. The abrt-action-analyze-c command is a fundamental component of the ABRT framework, integral to its ability to automatically process and categorize application-level crashes from C/C++ programs. It has been a part of ABRT's core functionality for many years, evolving with the tool to provide increasingly robust and automated crash analysis.

abrt(1), abrt-cli(1), abrt-action-analyze-kernel(1), gdb(1)