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

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

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

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

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

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

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

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

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

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

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

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