1. Introduction
Core dumps are an important part of debugging, as well as handling irrecoverable system errors and crashes. Once we ensure a core dump gets generated, we can turn to its analysis.
In this tutorial, we explore how to indicate the library paths when analyzing core dumps via the GNU Debugger (GDB). First, we discuss how and why core dumps come to be. After that, we check how to analyze them in GDB within an equivalent environment. Finally, we go through steps to handle a different setup than the one that generated the core dump.
We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.
2. Core Dump Configuration
Any application can trigger a core dump.
However, whether and where the kernel actually generates a core dump depends on multiple factors:
- core dump handler such as Apport, systemd-coredump, abrtd
- configuration of core dump handler
- contents of the /proc/sys/kernel/core_pattern file in the /proc pseudo-filesystem, which sets the core dump path
- limits and settings in /etc/security/limits.conf such as core
Yet, regardless of the way a core dump gets generated, part of it is always the raw data from the kernel. This data is compiled in a way that enables its use within debuggers such as the GNU Debugger (GDB).
However, even gdb may still require libraries that the core dump file uses. Depending on where and in what conditions the debugging takes place, these may not be immediately available or at the expected locations.
3. Set GDB Library Path
How we point GDB to the correct library paths relates to the differences between our debugging environment and the one that created the core dump.
3.1. Equivalent Environment
If, as is common, a core dump is analyzed on a machine with an equivalent hardware and software setup as the one that generated the data, we usually have a quick way to specify the library path before loading the core dump:
$ gdb
[...]
(gdb) set solib-search-path <LIBRARY_PATH>Here, we indicate LIBRARY_PATH as our current shared library path by [set]ting the solib-search-path variable.
However, there are cases when we need to make a few changes to our current environment or use a different one altogether.
3.2. Different Environment
If using a setup unlike the native one for the core dump, there are steps we can take to equalize the context:
- replicate entire library structure along with directories and files
- if needed, make replacements
- indicate the new directory path to GDB
Naturally, we can create symbolic links where possible.
After cloning the structure and making any modifications, we indicate the new path via the solib-absolute-prefix variable at the (gdb) prompt before loading a core dump:
$ gdb
[...]
(gdb) set solib-absolute-prefix <NEW_LIBRARY_PATH_PREFIX>In either of the cases above, we conclude by actually loading the core dump and related executable:
(gdb) file <PROBLEMATIC_EXECUTABLE_PATH>
(gdb) core-file <CORE_DUMP_FILE_PATH>At this point, we should be ready to start debugging.
4. Summary
In this article, we saw how to prepare and specify the library path when performing GDB core dump analysis.
In conclusion, even when debugging core dumps, we might need specific libraries as required by the original executable, so knowing how to acquire, structure, and point to them for our debugger can be critical.