Bug 215124

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
Bugzilla.

You may also try the upstream CVS snapshot if it helps:
http://www.jankratochvil.net/priv/gdb-6.5.50.20061111-cvs.x86_64.gz

You should be able to build the Java package I'm using from the original Sun
.bin file here:
http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=jdk-1.5.0_09-oth-JPR&SiteId=JSC&TransactionId=noreg
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
login: anonymous
password: e-mail address
cd /incoming
bi
put file
quit

Thanks!

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
gdb core.
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.)

core.java loading:
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.