[IPython-dev] IPython Crash Report

Fernando Perez fperez.net at gmail.com
Tue Nov 27 19:17:59 EST 2007


Thanks for the reports, Ville.

The one from the user on 0.7.1 is baffling, because he's not using any
of the gui or thread support, but that's also a fairly old version, so
who knows.

The one from 0.8.1 is using pylab is interesting, and I was just able
to reproduce it.  It's certainly an annoyance, but the interesting
thing is that ipython doesn't actually crash!  What happens is that if
by chance the KeyboardInterrupt fires exactly at the time that the Tk
event loop is running, the Tk exception handler raises the exception
directly into sys.excepthook, which is our crash handler.  So we
generate a report as if there had been a crash, when in reality
ipython is perfectly OK.

I don't see a way to prevent this, but you can tell from the reports
when this happens because you'll see *just* the Tkinter part of the
traceback and nothing else:

A problem occured executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.

/home/fperez/test/lib-tk/Tkinter.py in
__call__(self=<Tkinter.CallWrapper instance at 0x8d
127ac>, *args=('692', '??', '??', '??', '??', '16', '284484270', '??',
'572', '324', '??',
 '0', '??', '??', '.147924620', '6', '654', '994', '??'))
   1386         return self.tk.call('image', 'names')
   1387
   1388     def image_types(self):
   1389         """Return a list of all available image types (e.g.
phote bitmap)."""
   1390         return self.tk.call('image', 'types')
   1391
   1392
   1393 class CallWrapper:
   1394     """Internal class. Stores function to call when some user
   1395     defined Tcl function is called e.g. after an event occurred."""
   1396     def __init__(self, func, subst, widget):
   1397         """Store FUNC, SUBST and WIDGET as members."""
   1398         self.func = func
   1399         self.subst = subst
   1400         self.widget = widget
-> 1401     def __call__(self, *args):
        global __call__ = undefined
        self = <Tkinter.CallWrapper instance at 0x8d127ac>
        args = ('692', '??', '??', '??', '??', '16', '284484270',
'??', '572', '324', '??'
, '0', '??', '??', '.147924620', '6', '654', '994', '??')
   1402         """Apply first function SUBST to arguments, than FUNC."""
   1403         try:
   1404             if self.subst:
   1405                 args = self.subst(*args)
   1406             return self.func(*args)
   1407         except SystemExit, msg:
   1408             raise SystemExit, msg
   1409         except:
   1410             self.widget._report_exception()
   1411
   1412
   1413 class Wm:
   1414     """Provides functions for the communication with the
window manager."""
   1415
   1416     def wm_aspect(self,

KeyboardInterrupt:


This case isn't even caused by our own handling, since for Tk, the
threads stuff doesn't activate.  The Python interpreter has wired the
Tk event loop into its own, so this race condition can probably be
triggered by *any* python program that activates the Tkinter timer
callbacks.

If you get one of these that has wx, gtk or qt code in them, please
send them also my way.  I'd like to have a look at the structure of
the traceback, to see if any ideas come up.

Thanks again for the info,

f



More information about the IPython-dev mailing list