Useless stack trace by gdb(1) of "-g"-based core-file: nothing but "... in ?? ()"

Question

I'm getting the following (useless) stack trace from gdb:

$ gdb -e pqact -c core.6067
GNU gdb (GDB) Fedora (7.2-52.fc14)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
[New Thread 6067]
Cannot access memory at address 0x675
Cannot access memory at address 0x675
Cannot access memory at address 0x675
Cannot access memory at address 0x675
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Cannot access memory at address 0x675
Core was generated by `pqact -f WMO|CONDUIT|NGRID|EXP /local/ldm/etc/GEMPAK/pqact.gempak_upc'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000003790044d99 in ?? ()
Missing separate debuginfos, use: debuginfo-install glibc-2.13-2.x86_64
(gdb) where
#0  0x0000003790044d99 in ?? ()
#1  0x00000000903959a0 in ?? ()
#2  0x00000000900466e4 in ?? ()
#3  0x000000379080ee20 in ?? ()
#4  0x000000000040f81e in ?? ()
#5  0x000000379080ee60 in ?? ()
#6  0x0000000000000000 in ?? ()
(gdb) ^Z

The program was built with debugging enabled (libtool boilerplate omitted for clarity):

$ c99 ...  -g ... -c -o action.o action.c
$ c99 ...  -g ... -c -o filel.o filel.c
$ c99 ...  -g ... -c -o palt.o palt.c
$ c99 ...  -g ... -c -o pbuf.o pbuf.c
$ c99 ...  -g ... -c -o pqact.o pqact.c 
$ c99 ...  -g ... -c -o state.o state.c 
$ c99 -g -o pqact action.o filel.o palt.o pbuf.o pqact.o state.o ...

c99 is gcc on my system:

$ uname -a
Linux xxx.xxx.xxx.xxx 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
$ type c99
c99 is /usr/bin/c99
$ c99 -dumpversion
4.5.1

And the resulting program and core-file appear OK:

$ file pqact
pqact: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped
$ file core.6067
core.6067: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'pqact -f WMO|CONDUIT|NGRID|EXP /local/ldm/etc/GEMPAK/pqact.gempak_upc'
$ ldd pqact
linux-vdso.so.1 =>  (0x00007fff385ff000)
libldm.so.0 => /opt/ldm/ldm-6.13.0.0/lib/libldm.so.0 (0x00007ffcb2f3a000)
libgdbm.so.3 => /usr/lib64/libgdbm.so.3 (0x0000003790400000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00000030d8a00000)
libz.so.1 => /lib64/libz.so.1 (0x0000003d27e00000)
librt.so.1 => /lib64/librt.so.1 (0x0000003791800000)
libm.so.6 => /lib64/libm.so.6 (0x00007ffcb2c8c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003790800000)
libc.so.6 => /lib64/libc.so.6 (0x0000003790000000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003790c00000)
/lib64/ld-linux-x86-64.so.2 (0x000000378fc00000)

Any ideas why the stack-trace is useless?

Debugging optimised code is often near useless. 1) Use a more recent gcc, at least 4.8 and optimize for debugging only (recommended), or 2) Disable optimisations. — too honest for this site, Feb 22 '16 at 21:41
The stack entries `#0`, `#3`, `#5` fall into the address range of shared libraries. The last `#6` is suspicious because no code should be at address 0. So maybe, the stack is corrupted. — Martin Zabel, Feb 22 '16 at 21:57
@SteveEmmerson: And that is shown in the question - where? Please provide a [mcve]. — too honest for this site, Feb 22 '16 at 22:24

score 0 · Accepted Answer · edited May 23 '17 at 12:31

0

Any ideas why the stack-trace is useless?

The most common reason is that the binaries you give GDB to analyse the core do not match the binaries that were used at the time the core was produced.

For example, if your optimized binary crashed and produced core, and then you rebuild that binary without optimization, and try to use the new binary to analyze existing core, that wouldn't work.

Updating system libraries with newer version will also have that effect. So will copying core from one machine to another (unless system libraries match).

Useless stack trace by gdb(1) of "-g"-based core-file: nothing but "... in ?? ()"

1 Answers1