[Bug 1233185] Re: gdb-multiarch cannot read ARM cores: "wrong size gregset struct in core file"
Bug Watch Updater
1233185 at bugs.launchpad.net
Sun Nov 17 19:22:04 UTC 2013
** Changed in: gdb (Debian)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1233185
Title:
gdb-multiarch cannot read ARM cores: "wrong size gregset struct in
core file"
Status in “gdb” package in Ubuntu:
Fix Released
Status in “gdb” package in Debian:
Confirmed
Bug description:
We are getting complaints that the Launchpad apport retracers cannot
create proper symbolic stack traces for crashes on ARM. It seems gdb-
multiarch does not get along with our core dumps on ARM any more.
Reproducing the full apport-retrace environment is a bit complicated,
so I reduced this to a very simple test case:
Log into an ARM machine, like the Nexus G4, or porter-
armhf.canonical.com (shedir), using "schroot -c saucy-armhf".
1. create a core dump of bash:
$ cd /tmp/
$ bash -c 'ulimit -c unlimited; kill -SEGV $$'
2. Run it with gdb:
$ gdb --batch --ex 'file /bin/bash' --ex 'core-file core' --ex 'bt'
Core was generated by `bash -c ulimit -c unlimited; kill -SEGV $$'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181
../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden.
#0 0x00007f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81
#1 0x00000000004418a1 in kill_pid ()
[...]
There are not a lot of symbols as usually one doesn't have bash-
dbgsym etc. installed, but it's clearly able to produce a stack trace.
3. Run the same with gdb-multiarch:
$ gdb-multiarch --batch --ex 'file /bin/bash' --ex 'core-file core' --ex 'bt'
warning: wrong size gregset struct in core file
Core was generated by `bash -c ulimit -c unlimited; kill -SEGV $$'.
Program terminated with signal 11, Segmentation fault.
warning: wrong size gregset struct in core file
#0 <unavailable> in ?? ()
#0 <unavailable> in ?? ()
PC not available
FTR, Apport uses gdb-multiarch on amd64, and --ex 'set architecture
arm' --ex 'set gnutarget elf32-littlearm' to generate stack traces for
ARM coredumps on x86 (using binaries/libaries/debug symbols for ARM
that get unpacked into a temporary directory). The full invocation
looks something like this:
gdb-multiarch --ex 'set architecture arm' --ex 'set gnutarget
elf32-littlearm' --ex 'set debug-file-directory /tmp/s/usr/lib/debug'
--ex 'set solib-absolute-prefix /tmp/s' --ex 'file /tmp/s/bin/bash'
--ex 'core-file CoreDump' --ex 'bt full' --batch
But as gdb-multiarch does not even work on a native ARM machine for a
native ARM core dump of the very same machine/OS, I guess it's
something more fundamental which got broken there.
The same test case on amd64 works fine BTW, i. e. gdb-multiarch can
process amd64 binaries on amd64.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1233185/+subscriptions
More information about the foundations-bugs
mailing list