homepage

This snippet let my interpreter crash immediately:
> import sys, io
> io.open(sys.stdout.fileno(), 'wb')
> fd.close()
> sys.stdout.write("now writing on stdout will cause a crash")
That's happened on
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32
Windows 7 SP1 x64
The same code let Python 3.3.2 throw an exception like this:
Exception OSError: OSError(9, 'Bad file descriptor') in <_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp850'> ignored

the correct snippet is:
> fd = io.open(sys.stdout.fileno(), 'wb')
> fd.close()
> sys.stdout.write("now writing on stdout will cause a crash")

I don't get a crash under Linux. Perhaps this is a Windows-specific thing.

I can confirm that 2.7.2 hard-crashes as described on Windows. I'm not 
sure if I have the wherewithal to build 2.7 on this laptop to see if 
it's fixed in tip.
3.3 simply raises an IOError.

Here with 2.7.5 on Windows (Vista):
C:\Python27>python.exe
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import io, sys
>>> fd = io.open(sys.stdout.fileno(), 'wb')
>>> fd.close()
>>> sys.stdout.write("now writing on stdout will cause a crash")
At this point Windows pops up a box saying "python.exe has stopped working". I don't have a debug build available, and all I can find out is that it's a memory error in this line, somewhere in MS's C libraries:
and dword ptr ds:[718DD7A0h],0 
So, ya, it's a crash ;-)

Is this still an issue with later versions of 2.7? I'm sorry, I can't try this myself as I no longer run 2.7.

> I'm sorry, I can't try this myself as I no longer run 2.7.
You should install Python 2.7 if you want to work on Python 2.7 only issue. It's not so hard to install Python, especially on Windows (this issue looks to be specific to Windows).

Still an issue in 2.7.10rc0+. Here's a couple different reproducers that come closer to the heart of the matter:
"""
>>> import os
[43913 refs]
>>> os.close(1)
[43913 refs]
>>> input()
1
[43915 refs]
<crash>
"""
"""
>>> import os
[43913 refs]
>>> f = file('test', 'wb')
[43921 refs]
>>> os.close(f.fileno())
[43921 refs]
>>> f.flush()
[43921 refs]
>>> f.write('test')
[43921 refs]
>>> f.flush()
<crash>
"""
The problem appears to be calling fflush on a pointer to a closed file. In the first reproducer, this happens in myreadline.c, the second in fileobject.c.
I was interested enough to track it down; I'm not motivated enough to fix it since it appears to be broken only in 2.7.

On sudden inspiration, here's an even simpler reproducer:
"""
>>> import os
[43913 refs]
>>> os.close(2)
<crash>
"""

...and that one does crash 3.4, so I'm a bit more interested again. I'll try to look at this at the sprints.

PyOS_StdioReadline does an unchecked fflush(sys_stdout) and fflush(stderr). It only 'crashes' (the processes is intentionally killed by the CRT) if there's buffered data to flush. Since it prints the prompt to stderr, Zachary's example won't crash if sys.ps1 and sys.ps2 are empty strings. (Does anyone know why the prompt goes to stderr? readline on Linux uses stdout.) 
These calls should be guarded by _PyVerify_fd. On a related vein, in msg237845 I suggested adding a custom closer for file objects that checks _PyVerify_fd, but the check could also be added directly to close_the_file in fileobject.c. 
Here's the stack trace for 2.7 (it's similar for 3.4):
 C:\Program Files\Python27>cdb -xi ld python
 Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
 Copyright (c) Microsoft Corporation. All rights reserved.
 CommandLine: python
 Symbol search path is: symsrv*symsrv.dll*C:\Symbols*http://msdl.microsoft.com/download/symbols
 Executable search path is:
 (1078.11ec): Break instruction exception - code 80000003 (first chance)
 ntdll!LdrpDoDebuggerBreak+0x30:
 00000000`76e8cb70 cc int 3
 0:000> g
 Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit (AMD64)] on win32
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> os.close(2)
 ntdll!ZwTerminateProcess+0xa:
 00000000`76e3157a c3 ret
 0:000> kc
 Call Site
 ntdll!ZwTerminateProcess
 KERNELBASE!TerminateProcess
 MSVCR90!invoke_watson
 MSVCR90!invalid_parameter
 MSVCR90!write
 MSVCR90!flush
 MSVCR90!fflush_nolock
 MSVCR90!fflush
 python27!PyOS_StdioReadline
 python27!PyOS_Readline
 python27!tok_nextc
 python27!tok_get
 python27!PyTokenizer_Get
 python27!parsetok
 python27!PyParser_ParseFileFlagsEx
 python27!PyParser_ASTFromFile
 python27!PyRun_InteractiveOneFlags
 python27!PyRun_InteractiveLoopFlags
 python27!PyRun_AnyFileExFlags
 python27!Py_Main
 python!__tmainCRTStartup
 kernel32!BaseThreadInitThunk
 ntdll!RtlUserThreadStart

> This snippet let my interpreter crash immediately
Well, I don't understand the issue. If you write a bug, Python crashes. Ok, so? Please fix your bug. Don't expect Python from recovering from any bug.
The io stack of Python 3 is safer because it has a direct control on file descriptors, whereas Python 2 io stack relies on the C library "stdio.h".
I suggest to close this issue as "wontfix" and add it to the long list of "Bugs in the C stdio (used by the Python I/O)":
https://haypo-notes.readthedocs.org/python.html#bugs-in-the-c-stdio-used-by-the-python-i-o 

Python 3 raises an exception as expected, so I remove it from the Versions field. This issue is specific to Python 2, and it looks to be only reproductible on Windows. It's probably a bug in the C library (stdio.h).

The default (and standards-violating) behavior of the Windows CRT is to kill the process for a bad file descriptor, instead of just setting errno to EBADF. To work around this PyOS_StdioReadline needs to to check _Py_Verify_fd before calling fflush or writing to stderr. A similar check was added to my_fgets in 3.2.5 (see issue 14433), but it wasn't backported to Python 2.
The REPL in 3.x still uses C FILE streams, so this problem absolutely affects 3.x. (Except 3.5.0a2 and 3.5.0a3 have a hack that hides the problem. The hack has since been removed, so the problem has returned out of hiding in recent builds.) Previously I omitted the stack trace for brevity because it's virtually identical to 2.7, but here it is as justification for adding 3.x back to the issue's versions field.
 C:\Program Files\Python34>cdb -xi ld python
 Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
 Copyright (c) Microsoft Corporation. All rights reserved.
 CommandLine: python
 Symbol search path is: symsrv*symsrv.dll*C:\Symbols*http://msdl.microsoft.com/download/symbols
 Executable search path is:
 (1184.11f0): Break instruction exception - code 80000003 (first chance)
 ntdll!LdrpDoDebuggerBreak+0x30:
 00000000`76e8cb70 cc int 3
 0:000> bp ntdll!NtTerminateProcess
 0:000> g
 Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:16:31) [MSC v.1600 64 bit (AMD64)] on win32
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> os.close(2)
 Breakpoint 0 hit
 ntdll!NtTerminateProcess:
 00000000`76e31570 4c8bd1 mov r10,rcx
 0:000> kc
 Call Site
 ntdll!NtTerminateProcess
 KERNELBASE!TerminateProcess
 MSVCR100!invalid_parameter
 MSVCR100!invalid_parameter_noinfo
 MSVCR100!write
 MSVCR100!flush
 MSVCR100!fflush_nolock
 MSVCR100!fflush
 python34!PyOS_StdioReadline
 python34!PyOS_Readline
 python34!tok_nextc
 python34!tok_get
 python34!PyTokenizer_Get
 python34!parsetok
 python34!PyParser_ParseFileObject
 python34!PyParser_ASTFromFileObject
 python34!PyRun_InteractiveOneObject
 python34!PyRun_InteractiveLoopFlags
 python34!PyRun_AnyFileExFlags
 python34!run_file
 python34!Py_Main
 python!__tmainCRTStartup
 kernel32!BaseThreadInitThunk
 ntdll!RtlUserThreadStart
Additionally, here's a trace that demonstrates the silent handler hack that's present in 3.5.0a2:
 C:\Program Files\Python35>cdb -xi ld python
 Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
 Copyright (c) Microsoft Corporation. All rights reserved.
 CommandLine: python
 Symbol search path is: symsrv*symsrv.dll*C:\Symbols*http://msdl.microsoft.com/download/symbols
 Executable search path is:
 (1040.113c): Break instruction exception - code 80000003 (first chance)
 ntdll!LdrpDoDebuggerBreak+0x30:
 00000000`76e8cb70 cc int 3
 0:000> bp ucrtbase!set_thread_local_invalid_parameter_handler
 0:000> bp python35!_silent_invalid_parameter_handler
 0:000> g
With this hack in place, new_threadstate unconditionally sets the invalid parameter handler to _silent_invalid_parameter_handler (again, this has since been removed):
 Breakpoint 0 hit
 ucrtbase!set_thread_local_invalid_parameter_handler:
 000007fe`e47c8740 4053 push rbx
 0:000> kc
 Call Site
 ucrtbase!set_thread_local_invalid_parameter_handler
 python35!new_threadstate
 python35!_Py_InitializeEx_Private
 python35!Py_Main
 python!__scrt_common_main_seh
 kernel32!BaseThreadInitThunk
 ntdll!RtlUserThreadStart
 0:000> g
 Python 3.5.0a2 (v3.5.0a2:0337bd7ebcb6, Mar 8 2015, 07:17:31) [MSC v.1900 64 bit (AMD64)] on win32
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> os.close(2)
 Breakpoint 1 hit
 python35!_silent_invalid_parameter_handler:
 00000000`5f6e9d60 c20000 ret 0
 0:000> kc
 Call Site
 python35!_silent_invalid_parameter_handler
 ucrtbase!invalid_parameter
 ucrtbase!write
 ucrtbase!_acrt_stdio_flush_nolock
 ucrtbase!fflush_nolock
 ucrtbase!fflush
 python35!PyOS_StdioReadline
 python35!PyOS_Readline
 python35!tok_nextc
 python35!tok_get
 python35!parsetok
 python35!PyParser_ASTFromFileObject
 python35!PyRun_InteractiveOneObject
 python35!PyRun_InteractiveLoopFlags
 python35!PyRun_AnyFileExFlags
 python35!run_file
 python35!Py_Main
 python!__scrt_common_main_seh
 kernel32!BaseThreadInitThunk
 ntdll!RtlUserThreadStart
I think for 3.5 the affected code needs to be bracketed by _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH. This works on my personal build. See issue 23524 for more details regarding the new macros.

Here's a patch that adds the necessary _PyVerify_fd checking for 3.4. It won't apply to 2.7 (too many changes between 2.7 and 3.4), and applies to 3.5 but does nothing because of the new Invalid Parameter Handler introduced into 3.5.
It doesn't fix the problem completely: there is then a new crash in sysmodule.c/sys_write().
Unfortunately I didn't manage to write a test that replicates this whole issue and fails if Python crashes.

> The default (and standards-violating) behavior of the Windows CRT is to kill the process for a bad file descriptor, instead of just setting errno to EBADF.
Ah, if the issue is the behaviour of the MSVCRT on EBADF, Steve Dower can help you. He wrote the _Py_BEGIN_SUPPRESS_IPH/_Py_END_SUPPRESS_IPH thing for Python 3.5 and Visual Studio 2015 (Issue #23668).

As this is a fail-fast and not an uncontrolled crash, I vote to close as wontfix.
This only applies to security-fix versions, and it is not exploitable.

I agree this should probably be ignored for security-only branches. However, AFAIK 2.7 is still in bugfix status, not security-only. If there's interest, I'm happy to build with AMK's fix on 2.7 on Windows to see if it works, and if so provide a PR.