A core file is a dump of the memory and registers of a process at a specific point in time, usually at the moment that a process crashes. The default action for some signals, for example SIGSEGV (segmentation fault), is to generate a core file. A core file can be loaded into tools like GDB in order to understand why the process crashed.
Core files created from the process image don't contain any debug information for the executable or shared libraries. When the GNU Debugger (GDB) loads a core file, it needs access to the original executable to find the required debug information. Combining the debug information with the contents of the core file allows GDB to examine the state of the process at the moment it crashed.
The recently released GDB 16 contains improvements to how GDB reads the executable name, arguments, and environment from the core file. GDB's ability to automatically locate the executable corresponding to a core file has also been improved. In this article, we will examine three of those improvements.
Improved discovery of executable and arguments
The first improvement in GDB 16 core file loading is better discovery of executable and arguments. Along with the memory and registers, each core file contains additional notes. These notes are structured data that describe additional properties of the process. One of these notes is called NT_PRPSINFO. This note contains the executable filename and arguments used to start the process. Unfortunately, there are only 80 characters available within NT_PRPSINFO to store the executable name and arguments, so the information is truncated. Additionally, the executable name and arguments are stored in a single string, so it is not possible to know where the executable name ends and the command arguments begin.
In GDB 16, the executable and argument information is now found using a different core file note, NT_AUXV. It is more descriptive and not limited to 80 characters. This means that the full executable name and argument list should be visible, as seen in the Core was generated by ... line in the following session:
(gdb) core-file core.419153
[New LWP 419153]
Reading symbols from /tmp/this_is_a_directory_with_a_very_long_name_that_would_usually_be_truncated_due_to_its_length/gen-core...
Core was generated by `/tmp/this_is_a_directory_with_a_very_long_name_that_would_usually_be_truncated_due_to_its_length/gen-core aaa bbb ccc'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000401111 in foo () at gen-core.c:6
6 return *p;
(gdb) Viewable arguments and environment
The second core file-related improvement in GDB 16 is viewable arguments and environment. Now that GDB knows the full argument list, these arguments can be viewed using the show args command, as follows:
(gdb) show args
Argument list to give program being debugged when it is started is "aaa bbb ccc".
(gdb) This is useful if you have a long debug session and the original Core was generated by ... line has scrolled off the terminal.
In addition to being able to read the full arguments from the core file, GDB is also able to read the original environment of the crashing process. Prior to GDB 16, the show environment command would show the environment in which GDB was started. This is usually different from the environment that was in place when the core file was created. It is fixed, and GDB now shows the environment that was stored in the core file.
Consider this example of running a test program called gen-core and using env to start with an almost empty environment:
$$ env -i FOO=hello $PWD/gen-core aaa bbb ccc
Segmentation fault (core dumped)
$$ gdb -q
(gdb) core-file core.422146
[New LWP 422146]
Reading symbols from /tmp/this_is_a_directory_with_a_very_long_name_that_would_usually_be_truncated_due_to_its_length/gen-core...
Core was generated by `/tmp/this_is_a_directory_with_a_very_long_name_that_would_usually_be_truncated_due_to_its_length/gen-core aaa bbb ccc'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000401111 in foo () at gen-core.c:6
6 return *p;
(gdb) show environment
FOO=hello
(gdb) This will be useful when debugging a process that is affected by changes in its environment.
Better auto-loading of the executable
The third core file-related improvement in GDB 16 is something that we've already been using in the previous sessions. GDB 16 is better at locating and auto-loading the executable corresponding to a core file. Prior to GDB 16, GDB did have support for auto-loading the executable for a core file, but it was limited to locating system binaries. So, if an executable installed by your package manager crashed, and you opened the core file, there was a good chance GDB would be able to find the corresponding executable. But for non-system executables, GDB almost certainly would fail to auto-load the executable. In both of our previous sessions, we relied on this feature to auto-load the gen-core executable when we opened the core file.
There are still a few limitations. You need to compile with build-id support by passing the --build-id flag to the linker. GDB doesn't auto-load an executable unless it can find a matching build-id. This ensures that GDB doesn't load an executable that has changed since the creation of the core file. Similarly, the executable must be in its original location or in the same directory as the core file.
If the auto-loading fails, then it is still possible to tell GDB which executable matches the core file using the file command, just as you could with older versions of GDB. Likewise, if you use the file command to set the executable before loading the core file, then GDB will not try to auto-load a different executable.
Learn more about GDB 16 core files
Learn more about how core dumps are created with the man core command. On systems that use systemd, like Red Hat Enterprise Linux (RHEL) and Fedora, systemd manages core files by default. You can retrieve them with the coredumpctl command and get more details with the man coredumpctrl command. Review all GDB 16 improvements found in the release announcement.
