homepage

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