[Touch-packages] [Bug 1233185] Re: gdb-multiarch cannot read ARM cores: wrong size gregset struct in core file
This bug was fixed in the package gdb - 7.7.1-0ubuntu5~14.04.2 --- gdb (7.7.1-0ubuntu5~14.04.2) trusty-proposed; urgency=medium * SRU: Update for trusty. LP: #1351646. * Build the gdb-doc package from the gdb sources. -- Matthias Klose d...@ubuntu.com Wed, 08 Oct 2014 20:48:14 +0200 ** Changed in: gdb (Ubuntu Trusty) Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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” source package in Trusty: Fix Released Status in “gdb” package in Debian: Fix Released 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 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden. #0 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81 #1 0x004418a1 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1233185] Re: gdb-multiarch cannot read ARM cores: wrong size gregset struct in core file
I ran the test case on an armhf machine with gdb/gdb-multiarch 7.7.1-0ubuntu5~14.04.2 from trusty-proposed, and it works well now. I also copied the binary, libraries, and core dump to an amd64 machine and ran gdb-multiarch there, with the same result. So for this purpose, the trusty-proposed binary works fine now. ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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” source package in Trusty: Fix Committed Status in “gdb” package in Debian: Fix Released 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 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden. #0 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81 #1 0x004418a1 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1233185] Re: gdb-multiarch cannot read ARM cores: wrong size gregset struct in core file
** Changed in: gdb (Ubuntu Trusty) Status: Triaged = Fix Committed ** Tags removed: verification-failed ** Tags added: verification-needed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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” source package in Trusty: Fix Committed Status in “gdb” package in Debian: Fix Released 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 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden. #0 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81 #1 0x004418a1 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1233185] Re: gdb-multiarch cannot read ARM cores: wrong size gregset struct in core file
http://launchpad.net/ubuntu/+source/gdb/7.7.1-0ubuntu5~14.04.2 is available in trusty-proposed. Does that package include a fix for this bug? ** Branch unlinked: lp:ubuntu/saucy/gdb ** Branch unlinked: lp:ubuntu/saucy-proposed/gdb -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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” source package in Trusty: Triaged Status in “gdb” package in Debian: Fix Released 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 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden. #0 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81 #1 0x004418a1 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1233185] Re: gdb-multiarch cannot read ARM cores: wrong size gregset struct in core file
Yes, see the changelog. --- gdb-7.7/debian/changelog2014-06-30 18:22:58.0 + +++ gdb-7.7.1/debian/changelog 2014-10-08 18:48:25.0 + @@ -1,19 +1,52 @@ -gdb (7.7-0ubuntu3.2) trusty; urgency=medium +gdb (7.7.1-0ubuntu5~14.04.2) trusty-proposed; urgency=medium + + * SRU: Update for trusty. LP: #1351646. + * Build the gdb-doc package from the gdb sources. + + -- Matthias Klose d...@ubuntu.com Wed, 08 Oct 2014 20:48:14 +0200 + +gdb (7.7.1-0ubuntu5) utopic; urgency=medium + + * Fix regression introduced in previous upload, again supporting +powerpc64le in the multilib build. LP: #1233185. + + -- Matthias Klose d...@ubuntu.com Wed, 23 Jul 2014 15:19:13 +0200 + +gdb (7.7.1-0ubuntu4) utopic; urgency=medium [ Martin Pitt ] * debian/rules: Revert configuring with MULTIARCH_TARGET=all and go back to static list of targets. all is broken and does not work at least on ARM. (LP: #1233185) - -- Brian Murray br...@ubuntu.com Mon, 30 Jun 2014 11:22:03 -0700 + -- Brian Murray br...@ubuntu.com Mon, 30 Jun 2014 15:28:20 -0700 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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” source package in Trusty: Triaged Status in “gdb” package in Debian: Fix Released 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 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden. #0 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81 #1 0x004418a1 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1233185] Re: gdb-multiarch cannot read ARM cores: wrong size gregset struct in core file
Marking this, so that it is clear on http://people.canonical.com /~ubuntu-archive/pending-sru.html that it needs another upload. ** Tags added: verification-failed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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” source package in Trusty: Triaged Status in “gdb” package in Debian: Fix Released 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 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden. #0 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81 #1 0x004418a1 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1233185] Re: gdb-multiarch cannot read ARM cores: wrong size gregset struct in core file
The Launchpad retracers have used this proposed version for some time now, and I confirm this issue is fixed. E. g. bug 1347053 was retraced successfully. ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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” source package in Trusty: Fix Committed Status in “gdb” package in Debian: Fix Released 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 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden. #0 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81 #1 0x004418a1 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1233185] Re: gdb-multiarch cannot read ARM cores: wrong size gregset struct in core file
this introduces regressions for arm64 and ppc64el, please add the gnu triplets for these targets to the multiarch list. ** Changed in: gdb (Ubuntu) Status: Fix Released = Triaged ** Tags removed: verification-done ** Changed in: gdb (Ubuntu Trusty) Status: Fix Committed = Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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: Triaged Status in “gdb” source package in Trusty: Triaged Status in “gdb” package in Debian: Fix Released 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 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden. #0 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81 #1 0x004418a1 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1233185] Re: gdb-multiarch cannot read ARM cores: wrong size gregset struct in core file
this was ppc64el only, now fixed in utopic. I really would like to see the utopic version in trusty, re-adding the linaro changes and the updates of the 7.7.1 release, as documented at https://sourceware.org/gdb/ This is a minor corrective release over GDB 7.7, fixing the following issues: PR win32/14018 (pc register not available error on Windows) PR python/16547 (GDB crashing on gdb.python/py-linetable.exp) PR build/16550 (64-bit GDB doesn't build on Solaris) PR gdb/16626 (auto-load regression: gdb uses wrong file to test safeness) PR breakpoints/16292 (GDB oversteps a range in some cases.) PR gdb/16575 (stale breakpoint instructions in the code cache) PR gdb/16696 (AIX 32-bit cores, high section addresses) PR gdb/16721 (Erroneous backtrace on AVR) PR gdb/16832 (Erroneous backtrace on avrxmega architectures) PR build/16873 (GDB 7.7 does not build with GCC 4.9) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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: Triaged Status in “gdb” source package in Trusty: Triaged Status in “gdb” package in Debian: Fix Released 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 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden. #0 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81 #1 0x004418a1 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1233185] Re: gdb-multiarch cannot read ARM cores: wrong size gregset struct in core file
This bug was fixed in the package gdb - 7.7.1-0ubuntu5 --- gdb (7.7.1-0ubuntu5) utopic; urgency=medium * Fix regression introduced in previous upload, again supporting powerpc64le in the multilib build. LP: #1233185. -- Matthias Klose d...@ubuntu.com Wed, 23 Jul 2014 15:19:13 +0200 ** Changed in: gdb (Ubuntu) Status: Triaged = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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” source package in Trusty: Triaged Status in “gdb” package in Debian: Fix Released 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 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden. #0 0x7f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81 #1 0x004418a1 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
