Red Hat Bugzilla – Bug 215124
gdb crashes when applied to core dumps
Last modified: 2007-11-30 17:11:48 EST
Description of problem:
I have a core dump from Sun Java which causes gdb to dump core immediately upon
loading. The resulting core dump from gdb also causes gdb to core dump, but only
after using the backtrace command.
Version-Release number of selected component (if applicable):
This is gdb-6.5-13.fc6 on AMD64.
Steps to Reproduce:
1. Run "gdb gdb core"
2. Use the backtrace command
3. Wait a very long time for the command to complete.
Both core files are available if you want them; the java dump is 18 MB
compressed, the gcc dump is 14 MB compressed, both of which are above the
bugzilla upload limit (IIRC).
The java dump was generated from the java-1.5.0-sun-1.5.0.09-1jpp.x86_64
package, which was created from jdk-1_5_0_09-linux-amd64.bin (SHA-1:
This Bugzilla has limit 20000 KB so all the attachments you noted would fit in.
I will reproduce it otherwise but I find easier if you could attach it, thanks.
Created attachment 140973 [details]
the original core dump, which causes gdb to crash immediately on loading
Created attachment 140974 [details]
the resulting core dump from the crash loading the first core dump
I should add that the second core dump doesn't cause gdb to crash until it
finishes the backtrace, which is several hundred thousand frames long (I forget
the exact number, it's running in the background now with "set pagination off").
As you described, gdb cycling in:
#920 0x0000000000554ae4 in frame_unwind_register ()
#921 0x0000000000554864 in frame_register_unwind ()
I have to build the binaries to make it reproducible locally; if you could
provide the resulting binary .rpm it would be fine but it is too big for this
You may also try the upstream CVS snapshot if it helps:
You should be able to build the Java package I'm using from the original Sun
.bin file here:
and the JPackage nosrc.rpm I mentioned above.
Or you could wait for me to finish uploading the relevant pre-built binary
packages, which will finish in about 30 minutes.
Apparently I don't have web hosting which can handle several big files, so
you'll have build the Java package yourself.
However, I did test the upstream CVS snapshot on the Java core dump, and it
loads without problem.
I'm testing it on the gdb core dump now (which will take some time, it's only on
frame 41259 of I think ~152000)
The CVS snapshot build also crashes on the gdb core dump.
So could you please upload all the binaries relevant for the reproducibility and
not already uploaded here to:
$ ftp -n ftp.jankratochvil.net
password: e-mail address
Done. (I think, let me know if things were screwed up, every ftp client I tried
acted weird with java-1.5.0-sun-1.5.0.09-1jpp.x86_64.rpm)
I was checking now and - I was unable to reproduce the second crash - gdb on the
In the first crash it occurs only in one "rare" :-) combination:
(It probably got fixed by "gdb-6.5-matching_bfd_sections.patch" from upstream.)
OK gdb-6.5-13.fc6 glibc-2.5-3
BAD gdb-6.5-13.fc6 glibc-2.5-3 glibc-debuginfo-2.5-3
OK gdb-6.5-18.fc7 glibc-2.5-3 glibc-debuginfo-2.5-3
OK gdb-CVS glibc-2.5-3 glibc-debuginfo-2.5-3
OK gdb-6.5-8.fc6 glibc-2.5.90-11 glibc-debuginfo-2.5.90-11
OK gdb-6.5-13.fc6 glibc-2.5.90-11 glibc-debuginfo-2.5.90-11
Thanks for this notification but as gdb for FC6 is going to be updated these
days anyway this Bug does not require a specific fix.
Still I appreciate your valid bugreport.
forgotten (upstream release):
inv gdb-6.5 glibc-2.5.90-11 glibc-debuginfo-2.5.90-11
- The backtrace is not produced (no GNU hash).
(In reply to comment #11)
> I was unable to reproduce the second crash - gdb on the gdb core.
Oh, it really needs to run so long etc.
This case is not much a bug - gdb just crashed on exceeding its stack size while
analyzing the java core file.
It tried to access 0x7fff26905ff8 with $rsp at 0x7fff26906028 while the lower
stack limit was 0x7fff26906000, the stack size was 0xc00000==12MiB which
corresponds to the default `ulimit -s' setting of `10240 kbytes'.
This is `kernel' Component problem that it does not indicate stack exceeding in
some more user friendly way but just as a general segfault.