Apport crash while adding gdb_info to report when gdb couldn't load symbol map

Bug #1171484 reported by Nicolas Devillers
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apport (Ubuntu)
Fix Released
Undecided
Martin Pitt

Bug Description

Apport crash while trying to generate a report from a gdb crash core dump.

crash occure in function add_gdb_info() of file report.py on the line (around 687):
 if '"ERROR:' in self['GLibAssertionMessage']:

The crash happens because GLibAssertionMessage as not been affected as a key in self[].

It's because apport assume that the cmd invoking gdb : "out = _command_output(gdb_cmd).decode('UTF-8', errors='replace')"
will work and return correct value.

In my case the gdb invokation seems to give an incomplete result starting with :
"[New LWP 18326]\nwarning: Can\'t read pathname for load map: Erreur d\'entr\xe9e/sortie." ending with "No symbol table info available."

therefore parts list is composed of 1 element :

(pdb): len(parts)
1
(Pdb) parts[1]
*** IndexError: list index out of range

I guess a possible correction would be to add a check on the result of the gdb invocation or on the number of items in parts list line 681.

I could provide a patch but i'm not sure what is the cleanest way to correct this.

Affected version is apport 2.9.2.

Tags: patch gdb report
description: updated
description: updated
description: updated
Revision history for this message
Martin Pitt (pitti) wrote :

Fixed in trunk r2643.

affects: apport → apport (Ubuntu)
Changed in apport (Ubuntu):
status: New → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

---------------
apport (2.10.2-0ubuntu1) saucy; urgency=low

  * New upstream bug fix release:
    - Resolve symlinks in file references in Python crash signatures.
      (LP: #1179979)
    - Fix endless loop of EOFErrors with broken core dumps. (LP: #1168849)
    - report.py, add_gdb_info(): Fix crash if gdb did not determine an
      assertion message. (LP: #1171484)
    - apt/dpkg: Fix get_file_package()'s "release" field to actually mean
      DistroRelease:, not a distro code name. This now requires a previous
      call to install_packages() with a configdir, which needs to have a file
      <configdir>/<release>/codename with the release's code name in it.
    - sandboxutils.py: Call get_file_package() with the report's release, so
      that we actually get files from the target release, not the host
      release.
    - test_hookutils.py: Don't assume that /etc/motd exists.
  * Move to dh compat level 9.
 -- Martin Pitt <email address hidden> Wed, 22 May 2013 12:39:21 +0200

Changed in apport (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Nicolas Devillers (nicolas-devillers) wrote :

still affecting 2.10.2:

if '"ERROR:' in self.get('GLibAssertionMessage', ''):
   self['AssertionMessage'] = self['GLibAssertionMessage']
del self['GLibAssertionMessage']

---------------
the bug is now triggered by "del self['GLibAssertionMessage']"

stacktrace is:
  File "/usr/lib/python3/dist-packages/apport/report.py", line 692, in add_gdb_info
    del self['GLibAssertionMessage']
  File "/usr/lib/python3.3/collections/__init__.py", line 877, in __delitem__
    def __delitem__(self, key): del self.data[key]
KeyError: 'GLibAssertionMessage'

Changed in apport (Ubuntu):
status: Fix Released → New
Revision history for this message
Nicolas Devillers (nicolas-devillers) wrote :

This bug can also trigger the known bug of apport filling-up /tmp directory and the whole fs with apport-cli 2.10.2
Crashdump attached.

summary: - Apport crash while generating report from a gdb crash
+ Apport crash while adding gdb_info to report when gdb couldn't load
+ symbol map
Revision history for this message
Nicolas Devillers (nicolas-devillers) wrote :

Bug happens when gdb couldn't load the symbol map thus not able to provide GLibAssertionMessage or NihAssertionMessage.

The gdb output can't be splitted correctly with the used regexp. Here is a patch that prevent approt from crashing in this case. The patch may be improved by setting another regexp in such case to get stacktrace/disassembly/registers which are the informations that gdb can still give us.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "if gdb output contains "no symbol table info available" we don't parse it" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Changed in apport (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Revision history for this message
Martin Pitt (pitti) wrote :

Thanks! I restructured the code a bit to fix the KeyError. That should keep the field evaluation for the other parts.

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

This bug was fixed in the package apport - 2.12-0ubuntu2

---------------
apport (2.12-0ubuntu2) saucy; urgency=low

  * Merge from trunk:
    - sandboxutils.py, make_sandbox(): Install packages from Package: and
      Dependencies: fields also if we have a ProcMaps: field and there are any
      third-party packages. This fixes retracing crashes that use PPAs (as they
      don't have Contents.gz).
    - Robustify "progress bar visible" GTK and KDE UI checks for the faster
      collection due to dropping lsb_release.
 -- Martin Pitt <email address hidden> Fri, 02 Aug 2013 16:03:43 +0200

Changed in apport (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Nicolas Devillers (nicolas-devillers) wrote :

Hm I didn't check the latest patch but maybe it's too "large". I never get the [disassembly] field getting added since it surprisingly even when i got the symbols installed.

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.