not possible to retrace ppc64el crashes

Bug #1585702 reported by Brian Murray
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Apport
Fix Released
Undecided
Unassigned
apport (Ubuntu)
Fix Released
Medium
Martin Pitt

Bug Description

I was trying to retrace a ppc64el crash I found and ran into the following issue:

Calling gdb command: gdb-multiarch --ex 'set architecture powerpc:common' --ex 'set gnutarget elf32-powerpc' --ex 'set debug-file-directory /tmp/apport_sandbox_Y6fXCx/usr/lib/debug' --ex 'set solib-absolute-prefix /tmp/apport_sandbox_Y6fXCx' --ex 'file "/tmp/apport_sandbox_Y6fXCx//usr/bin/xfce4-panel"' --ex 'core-file /tmp/apport_core_N0Vrmm'
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
The target architecture is assumed to be powerpc:common
Architecture of file not recognized.
[New LWP 44625]
warning: Selected architecture powerpc:common is not compatible with reported target architecture powerpc:common64
/build/buildd/gdb-7.7.1/gdb/gdbarch.c:3217: internal-error: gdbarch_elf_make_msymbol_special: Assertion `gdbarch != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Revision history for this message
Brian Murray (brian-murray) wrote :

This is because of the following lines in report.py:

            # check for foreign architecture
            arch = self.get('Uname', 'none').split()[-1]
            if 'arm' in arch:
                command += ['--ex', 'set architecture arm', '--ex', 'set gnutarget elf32-littlearm']
            elif 'ppc' in arch:
                command += ['--ex', 'set architecture powerpc:common', '--ex', 'set gnutarget elf32-powerpc']
            # note, i386 vs. x86_64 is auto-detected just fine

I wonder if these are really needed as I retraced some arm64 crashes, uname with aarch64, and they retraced the same as when I added the following to report.py:

            if 'aarch64' in arch:
                command += ['--ex', 'set architecture aarch64', '--ex', 'set gnutarget elf64-littleaarch64']

Revision history for this message
Brian Murray (brian-murray) wrote :

I've removed the ppc check and ppc64el cores were detected and retraced fine.

Revision history for this message
Brian Murray (brian-murray) wrote :

I removed all the checks and armv7l crashes were retraced fine too.

Revision history for this message
Brian Murray (brian-murray) wrote :

If you don't want to remove the arch checks this works:

           if 'aarch64' in arch:
               command += ['--ex', 'set architecture aarch64', '--ex', 'set gnutarget elf64-littleaarch64']
           elif 'ppc64le' in arch:
               command += ['--ex', 'set architecture powerpc:common64', '--ex', 'set gnutarget elf64-powerpcle']

Changed in apport (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Brian Murray (brian-murray) wrote :

It's probably worth noting I was testing with the following version of gdb from Trusty:

 *** 7.7.1-0ubuntu5~14.04.2 0
        500 http://prodstack-zone-1.clouds.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages

Revision history for this message
Brian Murray (brian-murray) wrote :

I also tried my special gdb backport and that works well too.

ubuntu@juju-stg-ue-error-tracker-machine-10:/tmp$ apt-cache policy gdb
gdb:
  Installed: 7.10-1ubuntu3~14.04.1
  Candidate: 7.10-1ubuntu3~14.04.1
  Version table:
 *** 7.10-1ubuntu3~14.04.1 0
        500 http://ppa.launchpad.net/daisy-pluckers/daisy-seeds/ubuntu/ trusty/main amd64 Packages

Revision history for this message
Martin Pitt (pitti) wrote :

Brian, thanks for testing those. Back when I wrote this I had the impression that gdb sometimes got confused and needed those additional "set architecture" commands. But if current versions (≥ trusty) don't need it, so much the better!

Revision history for this message
Martin Pitt (pitti) wrote :
Changed in apport:
status: New → Fix Released
Changed in apport (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apport - 2.20.2-0ubuntu1

---------------
apport (2.20.2-0ubuntu1) yakkety; urgency=medium

  [ Brian Murray ]
  * data/general-hooks/ubuntu.py: tag bug reports 'apport-hook-error' if they
    have an attachment from an apport hook which crashed.

  [ Martin Pitt ]
  * New upstream release. Changes since our previous snapshot:
    - Don't ignore OSError in Report.add_gdb_info(), as we do want to fail with an
      useful error message if gdb cannot be called in apport-retrace. Move the
      catching to the UI as not having gdb installed is still fine for reporting
      clients. (LP: #1579949)
    - Show gdb error messages in Report.add_gdb_info() OSError exception when gdb
      fails. (LP: #1579897)
    - hookutils, attach_root_command_outputs(): Return str again, like before
      2.15.2. (LP: #1370259)
    - Stop issuing "set architecture" gdb commands on ARM and Power; these only
      applied to 32 bit platforms and are apparently not needed any more with
      recent gdb versions. (LP: #1585702)
    - Disable report.test_add_gdb_info_abort_libnih test case for now, as libnih
      is broken under current Ubuntu (LP: #1580601)

 -- Martin Pitt <email address hidden> Sun, 19 Jun 2016 22:17:35 +0200

Changed in apport (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.