[issue14433] Python 3 interpreter crash with memoryview and os.fdopen
New submission from Alexis Daboville : 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] a__: also happens under 3.2.2 under windows XP /and/ 3.2 under ubuntu natty [19:24] 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. -- messages: 156996 nosy: alexis.d priority: normal severity: normal status: open title: Python 3 interpreter crash with memoryview and os.fdopen type: crash versions: Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue14433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14433] Python 3 interpreter crash with memoryview and os.fdopen
Alexis Daboville added the comment: 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 D > at the interactive interpreter prompt. Not exactly, at least on Windows if I type ^Z + (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) -- ___ Python tracker <http://bugs.python.org/issue14433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14433] Python 3 interpreter crash with memoryview and os.fdopen
Alexis Daboville added the comment: > And D isn't how you shut down the interpreter on Windows, is it? No Z + is the equivalent (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? -- ___ Python tracker <http://bugs.python.org/issue14433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14433] Python 3 interpreter crash on windows when stdin closed in Python shell
Alexis Daboville added the comment: @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 -- ___ Python tracker <http://bugs.python.org/issue14433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16527] (very) long list of elif causes segfault
New submission from Alexis Daboville: Hi, It looks like using a very long list of elif makes CPython segfault. You can try it with the attached file, which looks like this: if False: pass elif False: pass # thousands of elifs elif False: pass $ python elif_segfault.py Segmentation fault. CPython versions tested: 3.x (all segfaults): 3.1 on Debian 3.2 on Arch Linux 3.3 on Windows 2.6 on Debian: segfaults with a longer list of elifs than the one in the attached file. The PyPy behaviour seems better: it raises 'RuntimeError: maximum recursion depth exceeded'. A possible cause (if I understood <http://greentreesnakes.readthedocs.org/en/latest/nodes.html#If> well) is that there are no elif nodes in the AST, elif are just plain ifs which are stored recursively in the else part of the previous if. (I'm not sure if that's an issue as it's not a real use case, but it makes CPython segfault and I was advised on #python-fr to report it anyway.) -- files: elif_segfault.py messages: 176081 nosy: alexis.d priority: normal severity: normal status: open title: (very) long list of elif causes segfault versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file28068/elif_segfault.py ___ Python tracker <http://bugs.python.org/issue16527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16527] (very) long list of elif causes segfault
Changes by Alexis Daboville : -- components: +Interpreter Core type: -> crash ___ Python tracker <http://bugs.python.org/issue16527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16527] (very) long list of elif causes segfault
Alexis Daboville added the comment: I had the feeling that there was a possible issue when reading how elifs were represented in the AST. I'm not insane enough to write so many elifs in a real program ;). I totally agree on the 'nice to have' part rather than 'required'. -- ___ Python tracker <http://bugs.python.org/issue16527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16527] (very) long list of elif causes segfault
Alexis Daboville added the comment:
I don't think it can be "fixed" with sys.setrecursionlimit for a few reasons:
* I think the issue arises when the AST is built. Otherwise if we put code
before the if it would execute. But that's not the case (try putting a
print('hello') before the if and it won't print anything).
- This also means that you cannot directly call sys.setrecursionlimit in the
file with the elifs.
- Though we can set recursion limit using a second file which will then
import the elifs file: I tried with different limits and CPython still crash in
the same way (and always with the same number of elifs, roughly, because I
didn't binary search for the exact amount of elifs).
- sys.setrecursionlimit controls the stack size of the running Python
program, while here we break C stack directly before running Python bytecode.
* When recursion limit is hit, an exception is raised, there's no segfault:
>>> def f():
... f()
...
>>> f()
# plenty of omitted lines
RuntimeError: maximum recursion depth exceeded
>>>
* Having a RuntimeError raised would be nice, though 'maximum recursion depth
exceeded' may not be the best possible error message as from a 'Python user'
POV there's no recursion here.
---
A possible solution would be, I guess, to store elifs as excepts are stored.
Instead of storing elifs recursively, the else part would just contain a list
of if nodes (and if there is a else, well just store an if True node).
Though I don't know how difficult it would be to implement that, or if it's
likely to break a lot of things which relies on ifs/elifs to be stored that way.
--
___
Python tracker
<http://bugs.python.org/issue16527>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19479] textwrap.dedent doesn't work properly with strings containing CRLF
New submission from Alexis Daboville:
If a string contains an empty line and is using CRLF newlines instead of LF
newlines textwrap.dedent doesn't work properly: it returns the original string
w/o dedenting it.
As far as I can tell it's because it considers the empty string to be the
longest common indent
(http://hg.python.org/cpython/file/2.7/Lib/textwrap.py#l372, '[^ \t\n]' matches
'\r').
Expected behavior: textwrap.dedent should work the same way whether lines are
separated by a single LF character or by CRLF.
To repro:
✓ 15:26 dabovill @ morag in /tmp/dedent $ cat dedent.py
import textwrap
lf = '\ta\n\tb\n\n\tc'
crlf = '\ta\r\n\tb\r\n\r\n\tc'
print('- lf')
print(lf)
print('- dedent(lf)')
print(textwrap.dedent(lf))
print('- crlf')
print(crlf)
print('- dedent(crlf)')
print(textwrap.dedent(crlf))
✓ 15:26 dabovill @ morag in /tmp/dedent $ python2.7 dedent.py
- lf
a
b
c
- dedent(lf)
a
b
c
- crlf
a
b
c
- dedent(crlf)
a
b
c
✓ 15:26 dabovill @ morag in /tmp/dedent $ python3.3 dedent.py
- lf
a
b
c
- dedent(lf)
a
b
c
- crlf
a
b
c
- dedent(crlf)
a
b
c
--
components: Library (Lib)
messages: 201975
nosy: alexis.d
priority: normal
severity: normal
status: open
title: textwrap.dedent doesn't work properly with strings containing CRLF
type: behavior
versions: Python 2.7, Python 3.3
___
Python tracker
<http://bugs.python.org/issue19479>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19479] textwrap.dedent doesn't work properly with strings containing CRLF
Alexis Daboville added the comment: Added patch. -- keywords: +patch Added file: http://bugs.python.org/file32519/dedent.patch ___ Python tracker <http://bugs.python.org/issue19479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20512] Python3.3 segfaults when using big5hkscs encoding
New submission from Alexis Daboville:
When using the 'big5hkscs' encoding it's possible to make Python3.3 segfault,
here is how to repro:
✗ 13:41 adaboville @ adoboville-mbp in ~ $ py3
Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 'nb'.encode('big5hkscs')
b'nb'
>>> 'nb'.encode('big5hkscs')
Segmentation fault: 11
Note that it doesn't crash on the first first line, but on the second (even
though both lines are the same). FWIW pypy3.3 doesn't crash:
✓ 13:43 adaboville @ adoboville-mbp in .../pypy3-2.1-beta1-osx64 $ bin/pypy
Python 3.2.3 (d63636b30cc0, Jul 30 2013, 07:02:48)
[PyPy 2.1.0-beta1 with GCC 4.2.1 Compatible Clang Compiler] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``why did you guys have to make the
builtin fortune more interesting than actual work? i just catched myself
restarting pypy 20 times''
>>>> 'nb'.encode('big5hkscs')
b'nb'
>>>> 'nb'.encode('big5hkscs')
b'nb'
>>>>
--
messages: 210258
nosy: alexis.d
priority: normal
severity: normal
status: open
title: Python3.3 segfaults when using big5hkscs encoding
type: crash
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue20512>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20512] Python3.3 segfaults when using big5hkscs encoding
Alexis Daboville added the comment: @David: yes, 10.9. -- ___ Python tracker <http://bugs.python.org/issue20512> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
