Comprehensive Guide to Analyzing Core Dump Files with Command-Line Parameters Using GDB

Fundamental Concepts of Core Dump Analysis

In Linux systems, when a program encounters a severe error (such as a segmentation fault), the system generates a core dump file that captures the program's memory state at the moment of crash. This file is crucial for post-mortem debugging, enabling developers to reconstruct the crash scenario and analyze the underlying causes.

Analysis of Common Usage Errors

Many developers, when first using GDB to debug core dump files, attempt to pass program command-line parameters directly to GDB, for example:

gdb ./exe -p param1 -i param2 -o param3 core.pid

This approach is incorrect because GDB interprets -p, -i, -o and similar parameters as its own command-line options rather than parameters for the debugged program. This prevents GDB from properly loading the core file and may generate misleading error messages.

Correct Core File Loading Methods

Method 1: Direct Loading Approach

The most basic usage involves passing both the executable and core file as direct parameters to GDB:

gdb <executable> <core-file>

For example:

gdb ./crash core.1234

Method 2: Using the -c Option

GDB provides a dedicated -c option to specify core files:

gdb <executable> -c <core-file>

This syntax more explicitly indicates the purpose of the core file.

Method 3: Interactive Loading

GDB can be started first, then the core file loaded in interactive mode:

gdb <executable>
(gdb) core <core-file>

This approach is suitable for scenarios requiring other debugging operations before loading the core file.

Handling Program Parameters

It is particularly important to note that when analyzing core dump files, there is no need (and no capability) to re-pass the program's command-line parameters. GDB automatically reads the complete context information from the core file, including command-line parameters used during program execution.

When using any of the above methods to load a core file, GDB displays information similar to:

Core was generated by `./crash -p param1 -o param2'.

This indicates that GDB has correctly identified the command-line parameters present during the program crash.

Complete Core Dump Analysis Workflow

Step 1: Environment Preparation

Ensure availability of the following files:

• Original executable file (must match the version that generated the core file)
• Core dump file (typically named core or core.pid)
• Program debug symbols (if compiled with -g option)

Step 2: Core File Loading

Use any of the previously described methods to load the core file. GDB automatically positions at the program crash location and displays relevant signal information.

Step 3: Crash Scene Analysis

After loading completes, use the following key commands for analysis:

• bt or where: Display call stack backtrace - the most crucial debugging command
• bt full: Display complete stack frame information including local variables
• info locals: Display values of local variables in current stack frame
• info registers: Display CPU register states
• frame <number>: Switch to specified stack frame
• up and down: Navigate up and down the call stack

Practical Case Study

Assume a program crash running with parameters -p param1 -o param2 experiences a segmentation fault and generates a core file. The debugging process proceeds as follows:

$ gdb ./crash core
GNU gdb (GDB) 7.1-ubuntu
...
Core was generated by `./crash -p param1 -o param2'.
Program terminated with signal 11, Segmentation fault.
#0  __strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
99    ../sysdeps/i386/i686/multiarch/../../i586/strlen.S: No such file or directory.
    in ../sysdeps/i386/i686/multiarch/../../i586/strlen.S
(gdb) bt
#0  __strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
#1  0x0804845d in process_data (data=0x0) at crash.c:15
#2  0x080484a2 in main (argc=3, argv=0xbffff344) at crash.c:25
(gdb) info locals
No locals in current frame.
(gdb)

From the call stack, we can see the program called a string length calculation function within process_data function, but passed a NULL pointer parameter, causing the segmentation fault.

Advanced Debugging Techniques

Examining Program Parameters

Although GDB automatically displays command-line parameters from the crash, they can also be manually inspected during debugging:

(gdb) print argv[0]
$1 = 0xbffff444 "./crash"
(gdb) print argv[1]
$2 = 0xbffff44c "-p"
(gdb) print argv[2]
$3 = 0xbffff44f "param1"

Analyzing Memory State

The core file contains a complete memory image at crash time, allowing examination of specific memory address contents:

(gdb) x/10x 0xbffff344
0xbffff344:     0xbffff444      0xbffff44c      0xbffff44f      0x00000000
0xbffff354:     0xbffff355      0xbffff35a      0xbffff35f      0xbffff364
0xbffff364:     0xbffff369      0x00000000

Cross-Platform Considerations

While this paper primarily discusses x86 architecture Linux environments, the concepts of core dump debugging apply to other platforms. As mentioned in Reference Article 2 regarding RISC-V architecture, although specific implementation details may differ, the fundamental debugging workflow and commands remain similar.

Best Practice Recommendations

• Always compile programs with -g option during development to preserve debug symbols
• Ensure core dump functionality is enabled in the system (ulimit -c unlimited)
• Regularly backup important core files, particularly crashes from production environments
• Perform comprehensive analysis combining log files and other debugging information

Conclusion

Proper usage of GDB for core dump file analysis is an essential skill in Linux development. The key understanding is that core files already contain complete state information from the program crash, including command-line parameters, thus eliminating the need to re-pass these parameters during debugging. Through systematic debugging workflows and proficient use of GDB commands, developers can rapidly identify and resolve program crash issues.