Issue
This is on Ubuntu 12.04, GDB version GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
The application I work on does dump core more times than I care to. When I start gdb as follows, I don't get any usable backtrace.
gdb --core <path to core dump>
GDB does show the full path of the process that caused the core dump along with command line arguments.
When on the gdb prompt, if I execute commands
file <path to executable>
core-file <path to core dump>
I do get a usable backtrace.
What is the difference between --core command line option and core-file command executed from the gdb prompt?
Is there any way I can do this in the command line? After all, gdb does know the path to the executable and core file name.
Solution
Is there anyway I can do this in command line.
Yes: gdb /path/to/exe /path/to/core
My main interest is why does gdb behaves differently.
It doesn't.
Most UNIX systems, in order to conserve disk space, do not dump file-backed read-only pages (such as program code) into the core file -- that code is already on disk, so why write it again? (This is actually configurable: see man core
and coredump_filter
).
But these read-only pages contain symbols (what you see in nm
and in backtrace
output), so if you don't tell GDB where the executable file is, then it can't produce a meaningful backtrace
.
After all, gdb does know the path to executable
No, it does not.
The kernel records incomplete info about the executable which produced the core. That info is unreliable:
- It may record relative path, e.g.
./a.out
and there is absolutely no guarantee that your current directory is the same at GDB analysis time as it was when the executable was invoked, and - There is only space for 16 characters in
elf_prpsinfo.pr_fname[]
, and anything longer than that will be truncated.
Answered By - Employed Russian Answer Checked By - Robin (WPSolving Admin)