Crash handler initialization is too aggressive #695

Closed
minrk opened this Issue Aug 12, 2011 · 2 comments

Comments

Projects
None yet
2 participants
@minrk
Member

minrk commented Aug 12, 2011

We currently initialize the crash-handler first, before instantiating any classes. This means that any errors in startup will get a massive, largely meaningless, crash report, that obscures relevant information more than it helps.

We should probably initialize the crash-handler very last, as part of the Application.start method, so that startup errors are raised as simple exceptions, rather than crashes.

For instance, it's trivially easy to crash IPython right now, by simply giving invalid values for configurables:

ipython --colors=bananaphone

The crash report gives the incorrect impression that IPython has done something wrong.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Aug 12, 2011

Member

It should probably also be an option to select a less verbose crash-handler, that doesn't print massive amounts of information, even when the crashes are real.

Member

minrk commented Aug 12, 2011

It should probably also be an option to select a less verbose crash-handler, that doesn't print massive amounts of information, even when the crashes are real.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Oct 17, 2011

Member

I see two ways to address the obvious issue above of bad user config causing crashes.

  1. Never crash on a TraitError. This is more aggressive protection from TraitErrors causing a crash report, and could potentially prevent the massive crash report if there really is an IPython bug that manifests as a TraitError.
  2. explicitly catch TraitErrors during initialization. This requires a lot more code fiddling, adding try/except blocks (either via decorators or context managers) to every initialize (or init_foo) method.
Member

minrk commented Oct 17, 2011

I see two ways to address the obvious issue above of bad user config causing crashes.

  1. Never crash on a TraitError. This is more aggressive protection from TraitErrors causing a crash report, and could potentially prevent the massive crash report if there really is an IPython bug that manifests as a TraitError.
  2. explicitly catch TraitErrors during initialization. This requires a lot more code fiddling, adding try/except blocks (either via decorators or context managers) to every initialize (or init_foo) method.

@fperez fperez closed this in 493f6d4 Nov 20, 2011

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this issue Nov 3, 2014

Merge pull request #1008 from minrk/excepthook
Use a much more restrained crash handler by default.

Now the excepthook shows a regular traceback, with a brief message about reporting bugs and how to enable to the big crash handler.  Our previous, extremely verbose crash handler can still be activated via `%config Application.verbose_crash=True`, so we can debug real crashes or ask users for extra detail easily.

Small fixes along the way:

* current Application added to configurables list, for use in %config.

* email addresses in full crash reports changed to ipython-dev, so they don't go straight to individual users.

Should close #695, and ameliorate #833 (doesn't fix the bug, but the message is more sensible).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment