classification
Title: Python 3 interpreter crash on windows when stdin closed in Python shell
Type: behavior Stage: needs patch
Components: Versions: Python 3.2, Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: alexis.d, amaury.forgeotdarc, brian.curtin, loewis, neologix, python-dev, r.david.murray, terry.reedy
Priority: normal Keywords: patch

Created on 2012-03-28 18:27 by alexis.d, last changed 2012-04-30 04:31 by loewis. This issue is now closed.

Files
File name Uploaded Description Edit
msvc.diff loewis, 2012-03-29 15:06 review
Messages (16)
msg156996 - (view) Author: Alexis Daboville (alexis.d) Date: 2012-03-28 18:27
Hi,

I was "playing" with memoryviews when I found this behaviour, launch the Python shell, and then enter the following:

>>> import os
>>> memoryview(os.fdopen(0))

A TypeError "cannot make memory view because object does not have the buffer interface" is raised and shown in the shell.

Then:
* On Windows 7, Python 3.2.2: Windows open a window with something like this "python.exe has stopped working"
* On CrunchBang Linux (Debian), Python 3.1.3: the shell exits (though echo $? print 0...).

On IRC, valhallasw was able to reproduce the bug:
[19:24] <valhallasw> a__: also happens under 3.2.2 under windows XP /and/ 3.2 under ubuntu natty
[19:24] <valhallasw> the latter just crashes without any message, the former gives the windows XP equivalent of the 'program has stopped working' message

I hope this help, if you need more information please ask.
msg156998 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2012-03-28 18:59
Hello,

This has actually nothing to do with memoryview:

"""
>>> import os
[67212 refs]
>>> stdin = os.fdopen(0)
[67234 refs]
>>> del stdin
__main__:1: ResourceWarning: unclosed file <_io.TextIOWrapper name=0 mode='r' encoding='UTF-8'>
[67260 refs]
>>> 
[67261 refs]
[44710 refs]
"""

When the object returned by os.fdopen() is garbage collected, the underlying FD is closed, and the interpreter aborts when it tries to read from stdin.
So it's not an issue, try calling memoryview(fdopen(<any FD other than 0,1,2>) and it'll work.
msg156999 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-03-28 19:08
> So it's not an issue, try calling memoryview(fdopen(<any FD other than 0,1,2>) and it'll work.

This is exactly why it's an issue. Python should not crash.
msg157001 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-03-28 19:28
To make this a little clearer, here's an even simpler example:

  >>> import os
  >>> os.fdopen(0)
<_io.TextIOWrapper name=0 mode='r' encoding='UTF-8'>
  >>> 1
__main__:1: ResourceWarning: unclosed file <_io.TextIOWrapper name=0 mode='r' encoding='UTF-8'>
  1
  >>>
  rdmurray@hey:~/python/p32>

What is happening here is that the file returned by os.fdopen is assigned to _, and then when I enter '1' *it* gets assigned to _, and the file gets gced and closed.  You can also see this directly:

  >>> import os
  >>> f = os.fdopen(0)
  >>> f.close()
  >>>
  rdmurray@hey:~/python/p32>

I explain this at length because I didn't understand it until I played around with it.

@Brian: this isn't a crash.  It is completely equivalent to pressing <ctl>D at the interactive interpreter prompt.
msg157002 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-03-28 19:31
Maybe it's a different reason, but some part of something about this crashes on Windows. "python.exe has stopped working" is a crash dialog.
msg157003 - (view) Author: Alexis Daboville (alexis.d) Date: 2012-03-28 19:33
First, thank you all for the explanations (sorry for the misleading title about the memoryview, should I rename it?).

> @Brian: this isn't a crash.  It is completely equivalent to pressing <ctl>D at the interactive interpreter prompt.

Not exactly, at least on Windows if I type ^Z + <enter> (which is the equivalent of ^D) the shell exits normally, while here there's an "annoying" error message (I don't say that it's important, just that that's not completely equivalent)
msg157004 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-03-28 19:33
Hmm.  And <ctl>D isn't how you shut down the interpreter on Windows, is it?  So maybe there is a Windows-specific bug here after all.  Or do you get that same dialog if you do the Windows equivalent of <ctl>D in a shell window (is that different from a CMD window, or the same?)
msg157013 - (view) Author: Alexis Daboville (alexis.d) Date: 2012-03-29 09:10
> And <ctl>D isn't how you shut down the interpreter on Windows, is it?

No <ctrl>Z + <enter> is the equivalent (<ctrl>D does nothing under Windows, except "printing" ^D).

And in a cmd window it just print another prompt (that's strange that it doesn't exit by the way...).

Also, I was thinking about the issue, is it normal to have this crash when we close directly the fd 0, whereas if I do sys.stdin.close() (which has sys.stdin.fileno() == 0) the Python shell continues to work properly?
msg157014 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2012-03-29 09:32
sys.stdin and others are created with "closefd=False", so close() has no effect.  Try os.close(0) instead...
msg157017 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-03-29 09:57
OK, let's reopen this for someone to investigate that Windows crash.
msg157023 - (view) Author: Alexis Daboville (alexis.d) Date: 2012-03-29 10:40
@Amaury: ok thanks, I never heard of this argument before.

I tried to reproduce the crash in the Python shell embedded in IDLE and there's no crash (same version 3.2.2, Windows 7): http://i.imgur.com/ayT96.png
msg157055 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-03-29 15:06
The crash occurs in the my_fgets implementation, namely when the CRT performs its (standards-violating) parameter validation. The attached patch works around this CRT bug (as has been done in other places already).
msg157163 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2012-03-31 03:05
64 bit win 7, 3.3.0a1 crashes also.
Idle shell just says that fd 0 is not valid, which I expect is correct for the socket replacement for sys.stdout.
msg159636 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2012-04-29 17:57
Martin, is there any reason not to commit your patch?
msg159665 - (view) Author: Roundup Robot (python-dev) Date: 2012-04-30 04:28
New changeset 2de5e9715fe9 by Martin v. Löwis in branch '3.2':
Issue #14433: Prevent msvcrt crash in interactive prompt when stdin is closed.
http://hg.python.org/cpython/rev/2de5e9715fe9

New changeset 2c27093fd11f by Martin v. Löwis in branch 'default':
Merge with 3.2: issue #14433
http://hg.python.org/cpython/rev/2c27093fd11f
msg159667 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-04-30 04:31
Out of the original report, ISTM that:
a) the exit of the interpreter on closing stdin is considered correct behavior, and
b) the crash on Windows is now fixed for 3.2, and 3.3

Hence I'm closing this issue as fixed.
History
Date User Action Args
2012-04-30 04:31:24loewissetstatus: open -> closed
resolution: fixed
messages: + msg159667

versions: + Python 3.3, - Python 3.1
2012-04-30 04:28:44python-devsetnosy: + python-dev
messages: + msg159665
2012-04-29 17:57:44neologixsetmessages: + msg159636
2012-03-31 03:05:12terry.reedysetnosy: + terry.reedy
messages: + msg157163
2012-03-29 15:06:29loewissetfiles: + msvc.diff

nosy: + loewis
messages: + msg157055

keywords: + patch
2012-03-29 10:40:24alexis.dsetmessages: + msg157023
2012-03-29 09:57:33r.david.murraysettitle: Python 3 interpreter crash on windows when stdin closed -> Python 3 interpreter crash on windows when stdin closed in Python shell
2012-03-29 09:57:02r.david.murraysetstatus: closed -> open
title: Python 3 interpreter crash with memoryview and os.fdopen -> Python 3 interpreter crash on windows when stdin closed
messages: + msg157017

resolution: not a bug -> (no value)
stage: resolved -> needs patch
2012-03-29 09:32:27amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg157014
2012-03-29 09:10:19alexis.dsetmessages: + msg157013
2012-03-28 19:33:50r.david.murraysetmessages: + msg157004
2012-03-28 19:33:16alexis.dsetmessages: + msg157003
2012-03-28 19:31:00brian.curtinsetmessages: + msg157002
2012-03-28 19:28:03r.david.murraysetstatus: open -> closed
nosy: + r.david.murray
messages: + msg157001

2012-03-28 19:08:38brian.curtinsetstatus: closed -> open
nosy: + brian.curtin
messages: + msg156999

2012-03-28 18:59:30neologixsetstatus: open -> closed

type: crash -> behavior

nosy: + neologix
messages: + msg156998
resolution: not a bug
stage: resolved
2012-03-28 18:27:05alexis.dcreate