Question

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 full path of process that caused core dump along with command line arguments.

When on gdb prompt, if I execute commands

file <path to executable>
core-file <path to core dump>

I do get usable backtrace.

What is the difference between --core command line option and core-file command executed from gdb prompt.

Is there anyway I can do this in command line. After all, gdb does know the path to executable and core file name.

Was it helpful?

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.
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top