Merge lp:~ev/apport/recoverable-errors into lp:apport
| Status: | Merged |
|---|---|
| Merged at revision: | 2440 |
| Proposed branch: | lp:~ev/apport/recoverable-errors |
| Merge into: | lp:apport |
| Diff against target: |
323 lines (+243/-6) 6 files modified
bin/apport-recoverable-problem (+46/-0) gtk/apport-gtk (+20/-3) kde/apport-kde (+17/-3) test/test_recoverable_problem.py (+83/-0) test/test_ui_gtk.py (+39/-0) test/test_ui_kde.py (+38/-0) |
| To merge this branch: | bzr merge lp:~ev/apport/recoverable-errors |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Martin Pitt | 2012-06-25 | Approve on 2012-07-13 | |
|
Review via email:
|
|||
Description of the Change
This branch adds a DBus service for reporting 'recoverable errors.' These are
problems which the application can handle, but still wishes to notify the user
and http://
As an example, the application may wish to notify the user because handling the
error resulted in degraded functionality. The user interface may fail to load
items, or the action just performed may not return any data. The developer may
wish for these types of errors to appear on http://
they may correct the root cause of the report.
I've implemented the DBus service and tests for both it and the UI frontends.
Thanks!
On Tue, Jun 26, 2012 at 9:32 AM, Martin Pitt <email address hidden> wrote:
> I like the general idea, thanks for this Evan!
Thanks!
> I would like to discuss/reconsider whether this really should be a D-BUS service; it would be the only piece of Apport functionality that is. All similar cases (package failure, gcc internal compiler error, uncaught Java exception, uncaught Python exception, GPU hang, etc.) have a CLI API in /usr/share/apport/ instead. E. g. gcc calls /usr/share/
I do agree that is ideal. I believe my original motivation for not
going down that road was that it's hard to provide structure through a
stdin pipe, and command line arguments have a maximum length.
I suppose we end up with something fairly loose no matter what, given
that the DBus service took a small number of fixed arguments and
pushed the rest through a dictionary. Would then you be happy with
something akin to the JVM hook, where it takes key value pairs
separated by null bytes to form the report, getting the PID from
getppid?
Sanity checks could then be done on the other then of the pipe to
ensure that there is enough present to generate a signature. This
might be via the reporter pushing a backtrace
(http://
traceback, or DuplicateSignature through the pipe as a key value pair.
| Martin Pitt (pitti) wrote : | # |
Evan Dandrea [2012-07-05 14:43 -0000]:
> I suppose we end up with something fairly loose no matter what, given
> that the DBus service took a small number of fixed arguments and
> pushed the rest through a dictionary. Would then you be happy with
> something akin to the JVM hook, where it takes key value pairs
> separated by null bytes to form the report, getting the PID from
> getppid?
Poor man's marshaller :-) Yes, I think that would be suitable as long
as we only need textual data. Binary data will most likely have null
bytes in them. But this does not seem to be a significant limitation
to me. If we need something more elaborate, we could also use an
existing marshaller such as pickle (but that would be difficult to
build from C clients) or GVariant.
Martin
--
Martin Pitt | http://
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
- 2405. By Evan on 2012-07-12
-
Instead of creating a DBus service to receive recoverable error reports, feed them into a binary with nul-separated key value pairs.
- 2406. By Evan on 2012-07-12
-
Make sure we're looking at the right report.
- 2407. By Evan on 2012-07-12
-
Refactor test for recoverable problems. Test for incomplete data.
- 2408. By Evan on 2012-07-12
-
One more.
- 2409. By Evan on 2012-07-12
-
Drop explicit python3 shebang.
- 2410. By Evan on 2012-07-12
-
Drop the DBus service.
- 2411. By Evan on 2012-07-12
-
s/RecoverableCr
ash/Recoverable Problem/ g - 2412. By Evan on 2012-07-12
-
Merge with trunk.
- 2413. By Evan on 2012-07-12
-
pep8 fixes.
- 2414. By Evan on 2012-07-12
-
Handle slight path differences in running tests.
- 2415. By Evan on 2012-07-12
-
Copyright header.
Okay, I've turned this into a separate binary with nul-separated key-value pairs sent over stdin. It's pretty simple, so perhaps I've missed something. :)
| Martin Pitt (pitti) wrote : | # |
This is indeed a lot simpler and more robust.
I made the following changes:
- Move from bin to data/ and rename to recoverable_
- Add an error message for an odd number of fields in stdin
- Drop the check for /proc/sys/
- In test_recoverabl
- Add docstrings to the tests
Merged into trunk now. Thanks a lot!


I like the general idea, thanks for this Evan!
I would like to discuss/reconsider whether this really should be a D-BUS service; it would be the only piece of Apport functionality that is. All similar cases (package failure, gcc internal compiler error, uncaught Java exception, uncaught Python exception, GPU hang, etc.) have a CLI API in /usr/share/apport/ instead. E. g. gcc calls /usr/share/ apport/ gcc_ice_ hook and submits the data on stdin and as CLI arguments. This approach reduces the asumptions how much of the system is working; adding dbus, dbus-python, and a working session bus are no small additions here. Also, by doing this on the session bus you exclude a lot of programs from this functionality: system services, user programs running from cron, or remote users.
Some nitpicks about the code (referencing line numbers in the "Preview diff" below):
5: please use /usr/bin/apport in trunk for now, as we keep the code working for Python 2 still (backports, retracer environment only has Python 2, etc.)
26, 37, others: Can we rename it to "RecoverablePro blem"? It might not be an actual crash (in fact, the way you describe it it is particularly _not_ a crash)
43-46: "Traceback" is Python specific, but InterpreterPath applies to all non-ELF programs (also Shell, Perl, Ruby, Java, JS, etc.); I would not assume having a stack trace here; if the caller actually has one, it can still supply it through the arbitrary key/value pairs (additional_keys), and strongly recommend (in the documentation for that functionality) that the caller adds a "DuplicateSigna ture" field.
26, 48: additional_keys is misleading, as it's a dictionary (but this might go away with turning this into CLI)
test_apport_ service. py: Unless you convert this to CLI, this needs to launch a local D-BUS and run on this (Gio.TestDBus is very nice for this, but only works in Quantal; dbus-launch works everywhere). During package builds and in autopkgtest we won't have a running session (nor system) bus.
Thanks!