Crash due to I/O in __del__

[gvanrossum]

BPO	20038
Nosy	@gvanrossum, @pitrou, @vstinner
Superseder	bpo-20037: Calling traceback.format_exception() during Pyhon shutdown does crash Python
Files	@bt.txt

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-12-21.11:57:55.859>
created_at = <Date 2013-12-21.01:35:32.372>
labels = ['type-crash']
title = 'Crash due to I/O in __del__'
updated_at = <Date 2013-12-21.11:57:55.858>
user = 'https://github.com/gvanrossum'

bugs.python.org fields:

activity = <Date 2013-12-21.11:57:55.858>
actor = 'pitrou'
assignee = 'none'
closed = True
closed_date = <Date 2013-12-21.11:57:55.859>
closer = 'pitrou'
components = []
creation = <Date 2013-12-21.01:35:32.372>
creator = 'gvanrossum'
dependencies = []
files = ['33241']
hgrepos = []
issue_num = 20038
keywords = []
message_count = 2.0
messages = ['206721', '206724']
nosy_count = 3.0
nosy_names = ['gvanrossum', 'pitrou', 'vstinner']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = '20037'
type = 'crash'
url = 'https://bugs.python.org/issue20038'
versions = ['Python 3.4']

[gvanrossum]

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.)

[vstinner]

This issue is a duplicate of issue bpo-20037.