Bug 215124 - gdb crashes when applied to core dumps
gdb crashes when applied to core dumps
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexandre Oliva
:
Depends On:
Blocks: 215197
  Show dependency treegraph
 
Reported: 2006-11-11 01:42 EST by Nicholas Miell
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: gdb-6.5-18.fc7.x86_64
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-09 12:19:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
the original core dump, which causes gdb to crash immediately on loading (17.80 MB, application/binary)
2006-11-11 18:05 EST, Nicholas Miell
no flags Details
the resulting core dump from the crash loading the first core dump (13.65 MB, application/x-bzip2)
2006-11-11 18:13 EST, Nicholas Miell
no flags Details

  None (edit)
Description Nicholas Miell 2006-11-11 01:42:27 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.

How reproducible:

Every time.

Steps to Reproduce:
1. Run "gdb gdb core"
2. Use the backtrace command
3. Wait a very long time for the command to complete.
4. SIGSEGV

Additional info:
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:
e2cf339798986d82547897c224de1629412f57b0) using
http://mirrors.dotsrc.org/jpackage/5.0/generic/non-free/SRPMS/java-1.5.0-sun-1.5.0.09-1jpp.nosrc.rpm
Comment 1 Jan Kratochvil 2006-11-11 14:33:52 EST
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.
Comment 2 Nicholas Miell 2006-11-11 18:05:39 EST
Created attachment 140973 [details]
the original core dump, which causes gdb to crash immediately on loading
Comment 3 Nicholas Miell 2006-11-11 18:13:45 EST
Created attachment 140974 [details]
the resulting core dump from the crash loading the first core dump
Comment 4 Nicholas Miell 2006-11-11 18:33:23 EST
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").
Comment 5 Jan Kratochvil 2006-11-11 19:03:27 EST
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
Comment 6 Nicholas Miell 2006-11-11 19:25:55 EST
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.
Comment 7 Nicholas Miell 2006-11-11 20:05:05 EST
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)
Comment 8 Nicholas Miell 2006-11-11 20:56:59 EST
The CVS snapshot build also crashes on the gdb core dump.
Comment 9 Jan Kratochvil 2006-11-15 05:19:55 EST
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!
Comment 10 Nicholas Miell 2006-11-16 00:20:53 EST
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)
Comment 11 Jan Kratochvil 2006-12-09 12:19:26 EST
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.
Comment 12 Jan Kratochvil 2006-12-09 12:20:35 EST
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).
Comment 14 Jan Kratochvil 2006-12-09 14:44:55 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.