[issue19050] [Python 2, Windows] fflush called on pointer to potentially closed file

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19050] [Python 2, Windows] fflush called on pointer to potentially closed file

[Steve Dower]

Steve Dower  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19050] [Python 2, Windows] fflush called on pointer to potentially closed file

[STINNER Victor]

STINNER Victor added the comment:

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

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19050
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19050] [Python 2, Windows] fflush called on pointer to potentially closed file

[A.M. Kuchling]

A.M. Kuchling added the comment:

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.

--
keywords: +patch
nosy: +akuchling
Added file: http://bugs.python.org/file38954/issue19050.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19050
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19050] [Python 2, Windows] fflush called on pointer to potentially closed file

[STINNER Victor]

STINNER Victor added the comment:

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

--
versions:  -Python 3.4, Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19050
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19050] [Python 2, Windows] fflush called on pointer to potentially closed file

[STINNER Victor]

STINNER Victor added the comment:

 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

--
title: fflush called on pointer to potentially closed file - [Python 2, 
Windows] fflush called on pointer to potentially closed file

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19050
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19050] [Python 2, Windows] fflush called on pointer to potentially closed file

[eryksun]

eryksun added the comment:

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\Python34cdb -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 8003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
`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:
`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\Python35cdb -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 8003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
`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:
07fe`e47c8740 4053pushrbx
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:
`5f6e9d60 c2  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.

--
versions: +Python 3.4, Python 3.5

___
Python tracker rep...@bugs.python.org