[Bug 1579897] Re: report's _command_output function doesn't always return the error

Launchpad Bug Tracker 1579897 at bugs.launchpad.net
Mon Jun 20 07:47:06 UTC 2016


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 <martin.pitt at ubuntu.com>  Sun, 19 Jun 2016 22:17:35
+0200

** Changed in: apport (Ubuntu)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1579897

Title:
  report's _command_output function doesn't always return the error

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  Fix Released

Bug description:
  Apparently, the following gdb command fails but the error output is
  not in subprocess's err output but in stdout.

  > /srv/daisy.staging.ubuntu.com/staging/apport-2984/apport/report.py(104)_command_output()
  -> if sp.returncode == 0:
  (Pdb) l
   99         '''
  100         sp = subprocess.Popen(command, stdout=subprocess.PIPE, stderr=stderr)
  101     
  102         (out, err) = sp.communicate(input)
  103         import pdb; pdb.set_trace()
  104  ->     if sp.returncode == 0:
  105             return out
  106         else:
  107             if err:
  108                 err = err.decode('UTF-8', errors='replace')
  109             else:
  (Pdb) command
  ['/tmp/apport_sandbox__6uwrvhm/usr/bin/gdb', '--ex', 'set debug-file-directory /tmp/apport_sandbox__6uwrvhm/usr/lib/debug', '--ex', 'set solib-absolute-prefix /tmp/apport_sandbox__6uwrvhm', '--ex', 'file "/tmp/apport_sandbox__6uwrvhm//usr/bin/cdparanoia"', '--ex', 'core-file /tmp/apport_core_756rypvb', '--batch', '--ex', 'set backtrace limit 2000', '--ex', 'p -99', '--ex', 'print (char*) __nih_abort_msg', '--ex', 'p -99', '--ex', 'print __abort_msg->msg', '--ex', 'p -99', '--ex', 'print __glib_assert_msg', '--ex', 'p -99', '--ex', 'bt full', '--ex', 'p -99', '--ex', 'x/16i $pc', '--ex', 'p -99', '--ex', 'thread apply all bt full', '--ex', 'p -99', '--ex', 'info registers']
  (Pdb) out
  b'/tmp/apport_sandbox__6uwrvhm/usr/bin/gdb: error while loading shared libraries: libpython3.5m.so.1.0: cannot open shared object file: No such file or directory\n'

  Because stdout is not included in the raised error message it ended up
  being hard to find out what the error really was.

  111             raise OSError('Error: command %s failed with exit code %i: %s' % (
  112                 str(command), sp.returncode, err))

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1579897/+subscriptions



More information about the foundations-bugs mailing list