I have a core file generated from a segfault. When I try to load it into gdb, it doesn't appear to matter how I load it or if I use the correct executable or not - I always get this warning from gdb about the core file being truncated:
$ gdb -q /u1/dbg/bin/exdoc_usermaint_pdf_compact /tmp/barry/core.exdoc_usermaint.11
Reading symbols from /u1/dbg/bin/exdoc_usermaint_pdf_compact...done.
BFD: Warning: /tmp/barry/core.exdoc_usermaint.11 is truncated: expected core file size >= 43548672, found: 31399936.
warning: core file may not match specified executable file.
Cannot access memory at address 0x7f0ebc833668
GNU gdb (GDB) Fedora (7.0.1-50.fc12)
Copyright (C) 2009 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:
$ uname -a
Linux somehost 188.8.131.52-170.fc12.x86_64 #1 SMP Mon Sep 27 17:23:59 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
On a modern Linux system, core dump files are formatted using the ELF object file format, with a specific configuration. ELF is a structured binary file format, with file offsets used as references between data chunks in the file.
For core dump files, the e_type field in the ELF file header will have the value ET_CORE.
Unlike most ELF files, core dump files make all their data available via program headers, and no section headers are present. You may therefore choose to ignore section headers in calculating the size of the file, if you only need to deal with core files.
To calculate the ELF file size:
If you find the offsets to the program header or section header tables are past the end of the file, then you will not be able to calculate an expected file size, but you will know the file has been truncated.
Although an ELF file could potentially contain unaddressed regions and be longer than the calculated size, in my limited experience the files have been exactly the size calculated by the above method.
gdb likely performs a calculation similar to the above to calculate the expected core file size.
In short, if gdb says your core file is truncated, it is very likely truncated.
One of the most likely causes for truncated core dump files is the system ulimit. This can be set on a system-wide basis in /etc/security/limits.conf, or on a per-user basis using the ulimit shell command [footnote: I don't know anything about systems other than my own].
Try the command "ulimit -c" to check your effective core file size limit:
$ ulimit -c unlimited
Also, it's worth noting that gdb doesn't actually refuse to operate because of the truncated core file. gdb still attempts to produce a stack backtrace and in your case only fails when it tries to access data on the stack and finds that the specific memory locations addressed are off the end of the truncated core file.