write test for anti-Ubuntu-crash-reporter exception-catching code

[ChosenOne]

Hey,

I just noticed that 'tahoe put' (without any parameters, in an unconfigured state) might throw an IOError (No such file or directory: u'~/.tahoe/node.url').

While this itself is a little unfriendly towards user, it is also causing the Ubuntu 'Crash report' application the show up. The 'crash report' appears to be a new features in Ubuntu 12.04. Apparently, it's sitting in the background looking for failures/exceptions and nags people who know what they do :P

This may lead to bad statistics at Ubuntu about tahoe's stability. Also, it's pretty annoying. :)

(See attachment)

[ChosenOne]

ubuntu crash report (collapsed)

[ChosenOne]

I have verified this with a fresh Ubuntu installation. The reporter is called "apport" and according to /etc/default/apport it is enabled by default now.

[davidsarah]

Grr, silly Ubuntu devs making our lives harder for no good reason.

"If you notice further problems, try restarting the computer."

What is this, Windows? As if restarting will help for 99% of conditions this detects :-(

[ChosenOne]

See files in /etc/python*/sitecustomize.py:

# install the apport exception handler if available
try:
    import apport_python_hook
except ImportError:
    pass
else:
    apport_python_hook.install()

I traced it back into the apport-package, ubuntu provides. Installing the hook does the following

    sys.excepthook = apport_excepthook

This means that your python environment is modified like this:

print repr(sys.excepthook)
print sys.excepthook.func_name
print type(sys.excepthook)'
# <function apport_excepthook at 0x7fb84e5335f0>
# apport_excepthook
# <type 'function'>

A dirty, fix for this ticket could be (untested!)

import sys
import types # for comparison. can we do this better?
if types.FunctionType == type(sys.excepthook):
    if sys.excepthook.func_name == 'apport_excepthook':
        sys.excepthook = lambda *x: None
   

[davidsarah]

Thanks ChosenOne for investigating this.

Knowing that it is implemented by sys.excepthook, we can easily prevent that from triggering, by catching exceptions at the entry point to the CLI.

[davidsarah]

Catch exceptions from CLI in order to prevent the Ubuntu crash monolog from triggering. refs #1746

[davidsarah]

ChosenOne?, please test this patch against trunk.

[ChosenOne]

The exception remains, but apport is not started. Patch works.

[warner]

I'm +1 for this for CLI commands like "tahoe put" and friends (although maybe we should just rewrite those commands to never report gateway failures or bad arguments as exceptions, always emitting a nicer error message).

I'm less confident about doing this for "tahoe start", if only for the case where we eventually have a double-clickable "launch tahoe" icon, and if the only way that an exception during startup can be noticed is by a GUI apport hook that notices the exception and reports it in a dialog (monolog) box.

I guess at a more fundamental level, Ubuntu (via apport) is telling us that exceptions are not an acceptable way to deliver "user made a mistake" error messages to users, which I can't entirely disagree with (although it's still pretty annoying).

[davidsarah]

If we wanted to trap uncaught errors and display a modal dialog, we should do that. But I can't think why we would want it to look anything like the Ubuntu one, and I dislike intensely the idea that the error reporting behaviour of our code should be suddenly changed by distribution developers who obviously have no clue about usable error reporting should work.

In any case, this patch doesn't change the (visible) behaviour of tahoe start from what it does without apport.

[gdt]

In general, it seems a good rule is that python exceptions from CLI commands should only hit top-level and be user-perceptible if there is a code bug. Python backtraces are not really so different from "segementation violation -- core dumped".

[zooko]

I agree with gdt.

Once we've fixed all such places in our code, so that we never intentionally display a Python backtrace to a user, then the behavior of the apport hook may not be inappropriate.

Any case where our code displays a Python backtrace to a user should be ticketed with the error keyword:

​https://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~error&order=priority

[david-sarah@…]

In 2ee1bc7148d45719:

(The changeset message doesn't reference this ticket)

[davidsarah]

This is fixed; please open another ticket or tickets for any inappropriate backtraces.

[davidsarah]

Reopening because it needs a test.

[warner]

updating title, priority

[warner]

oh, also, ChosenOne's work is done here, assigning back to davidsarah for the test-writing

[david-sarah@…]

In 5889/cloud-backend:

[rebased for cloud-backend] Catch exceptions from CLI in order to prevent the Ubuntu crash monolog from triggering. refs #1746

[davidsarah]

Please review: ​https://github.com/davidsarah/tahoe-lafs/commit/64e326e211d4b08e543feb98c45d382dce519fab

[amiller]

I've reviewed this patch and its test. The patch catches all exceptions in the CLI by having a try/catch around the 'run' function for all CLI commands. The test correctly distinguishes between when this exception is caught rather than propagated. I haven't directly checked that this solves the ubuntu app reporting problem, since I don't know how to build the ubuntu version. But ChosenOne?'s analysis about how catching the exception solves the problem makes sense.

[davidsarah]

Fixed in ​52a583ce.