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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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.
|
|
Date |
User |
Action |
Args |
2022-04-11 14:57:28 | admin | set | github: 58638 |
2012-04-30 04:31:24 | loewis | set | status: open -> closed resolution: fixed messages:
+ msg159667
versions:
+ Python 3.3, - Python 3.1 |
2012-04-30 04:28:44 | python-dev | set | nosy:
+ python-dev messages:
+ msg159665
|
2012-04-29 17:57:44 | neologix | set | messages:
+ msg159636 |
2012-03-31 03:05:12 | terry.reedy | set | nosy:
+ terry.reedy messages:
+ msg157163
|
2012-03-29 15:06:29 | loewis | set | files:
+ msvc.diff
nosy:
+ loewis messages:
+ msg157055
keywords:
+ patch |
2012-03-29 10:40:24 | alexis.d | set | messages:
+ msg157023 |
2012-03-29 09:57:33 | r.david.murray | set | title: 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:02 | r.david.murray | set | status: 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:27 | amaury.forgeotdarc | set | nosy:
+ amaury.forgeotdarc messages:
+ msg157014
|
2012-03-29 09:10:19 | alexis.d | set | messages:
+ msg157013 |
2012-03-28 19:33:50 | r.david.murray | set | messages:
+ msg157004 |
2012-03-28 19:33:16 | alexis.d | set | messages:
+ msg157003 |
2012-03-28 19:31:00 | brian.curtin | set | messages:
+ msg157002 |
2012-03-28 19:28:03 | r.david.murray | set | status: open -> closed nosy:
+ r.david.murray messages:
+ msg157001
|
2012-03-28 19:08:38 | brian.curtin | set | status: closed -> open nosy:
+ brian.curtin messages:
+ msg156999
|
2012-03-28 18:59:30 | neologix | set | status: open -> closed
type: crash -> behavior
nosy:
+ neologix messages:
+ msg156998 resolution: not a bug stage: resolved |
2012-03-28 18:27:05 | alexis.d | create | |