I was writing a new Tulip example (a cache client and server, not yet public) and I noticed that when I interrupted the client with ^C I got a traceback (expected) followed by a segfault (unexpected).  This is on OSX 10.8 but I don't think it is platform dependent.

A little experiment showed that this only happened with Python 3.4 and only with the latest Tulip, where Future has a __del__ method.  

According to gdb, the segfault happens on the first line of PyModule_GetState(), because the argument 'm' is NULL.

Putting a NULL check in this function averts the segfault but give the following disturbing extra traceback:

--- Logging error ---
Traceback (most recent call last):
Exception ignored in: <bound method Task.__del__ of Task(<testing>)<exception=KeyboardInterrupt()>>
Traceback (most recent call last):
  File "/Users/guido/tulip/asyncio/futures.py", line 177, in __del__
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1278, in error
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1384, in _log
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1394, in handle
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1456, in callHandlers
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 835, in handle
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 959, in emit
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 888, in handleError
  File "/Users/guido/cpython/Lib/traceback.py", line 169, in print_exception
  File "/Users/guido/cpython/Lib/traceback.py", line 153, in _format_exception_iter
  File "/Users/guido/cpython/Lib/traceback.py", line 18, in _format_list_iter
  File "/Users/guido/cpython/Lib/traceback.py", line 65, in _extract_tb_or_stack_iter
  File "/Users/guido/cpython/Lib/linecache.py", line 15, in getline
  File "/Users/guido/cpython/Lib/linecache.py", line 41, in getlines
  File "/Users/guido/cpython/Lib/linecache.py", line 126, in updatecache
  File "/Users/guido/cpython/Lib/tokenize.py", line 431, in open
TypeError: bad argument type for built-in operation

This suggests the problem is triggered by some I/O due to the exception logging in the __del__ method.

The gdb traceback (too big to post here) tells me that this PyModule_GetState() call is in the IO_STATE macro in textiowrapper_init().  The whole thing seems to be in a GC run called from Py_Finalize().  Check out the attached @bt.txt.

Any ideas?  (The TypeError is simply what PyModule_GetState() returns for a non-module argument -- I made it take the same exit path for NULL.)