homepage

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.

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.

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

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.

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.

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)

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

> 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?

sys.stdin and others are created with "closefd=False", so close() has no effect. Try os.close(0) instead...

OK, let's reopen this for someone to investigate that Windows crash.

@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 

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

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.

Martin, is there any reason not to commit your patch?

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 

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.