[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