Title: assertion failures on Windows in Python/traceback.c in case of a bad
Type: crash Stage:
Components: IO Versions: Python 3.11, Python 3.10, Python 3.9
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Oren Milman, iritkatriel
Priority: normal Keywords:

Created on 2017-09-13 08:46 by Oren Milman, last changed 2021-10-18 22:41 by iritkatriel.

Messages (2)
msg302036 - (view) Author: Oren Milman (Oren Milman) * Date: 2017-09-13 08:46
the following code causes an assertion failure on my Windows:
import io
def _bad_open(*args):
    return 42 = _bad_open


this is because _Py_DisplaySourceLine() (in Python/traceback.c) assumes that
the return value of is valid.

IIUC, this is actually a debug assertion failure in Windows code, in
_get_osfhandle() (which is called by _Py_dup() (in Python/fileutils.c)).
(also, on my Ubuntu VM, there is no assertion failure.)

the following code causes a similar assertion failure:
import io
def _bad_open1(*args): = _bad_open2
    raise Exception

def _bad_open2(*args):
    return 42 = _bad_open1


this is because _Py_FindSourceFile() assumes that the return value of
is valid, and returns it to _Py_DisplaySourceLine(), which also assume it is

I thought about adding a check in _Py_DisplaySourceLine(), before calling
PyObject_AsFileDescriptor(), such as:
PyObject_IsInstance(binary, (PyObject*)&PyIOBase_Type);
but I am not sure whether we should use PyIOBase_Type outside of the io module.

note that even with such a check, one could still write a _bad_open() that
returns a subclass of IOBase, whose fileno() method returns a bad file
#15263 (and specifically mentions
msg404235 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-10-18 22:41
Reproduced on 3.11.
Date User Action Args
2021-10-18 22:41:38iritkatrielsetnosy: + iritkatriel

messages: + msg404235
versions: + Python 3.9, Python 3.10, Python 3.11, - Python 3.7
2017-09-13 08:46:38Oren Milmancreate