[issue33186] Memory corruption with urllib.parse

2018-03-31 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: Actually, Alexey shared this problem with me orally first, and then asked to have a look at his report, and I felt that just describing the technical details about what is going on is not enough, and suggested to include a

[issue33186] Memory corruption with urllib.parse

2018-03-30 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: > 1. The described result can be valid if there are "doubly quoted" strings in > the input list. To check this I've modified your testcase.py: diff --git a/testcase.py b/testcase.py index b597205..fefcef2 100755 -

[issue33186] Memory corruption with urllib.parse

2018-03-30 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: > a list contains elements that have never been appended Why do we think that it's true? 1. The described result can be valid if there are "doubly quoted" strings in the input list. 2. Also, there could be a bug

[issue33186] Memory corruption with urllib.parse

2018-03-30 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: The bad results are also reproducible with: # dpkg -l python3.2 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Stat

[issue33186] Memory corruption with urllib.parse

2018-03-30 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: I've tested this on a e2k machine (e2k is a VLIW/EPIC architecture, similar to ia64), where python3 3.5 has been compiled with a completely different proprietary compiler, and got the same bad result. python3-3.5.1-alt7.3 (Th

[issue33186] Memory corruption with urllib.parse

2018-03-30 Thread Ivan Zakharyaschev
Change by Ivan Zakharyaschev <i...@altlinux.org>: -- nosy: +imz ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33186> ___ __

[issue33153] interpreter crash when multiplying large tuples

2018-03-27 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: It was run in i586 chroot on x86_64. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33153] interpreter crash when multiplying large tuples

2018-03-27 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: The traceback: [builder@localhost ~]$ python -c 'x = ("a", "b") * 2**20; x *= 2**20' Segmentation fault (core dumped) [builder@localhost ~]$ gdb python core.23284 GNU gdb (GDB) 7.9-alt4 (ALT) Copyright (C) 201

[issue33153] interpreter crash when multiplying large tuples

2018-03-27 Thread Ivan Zakharyaschev
New submission from Ivan Zakharyaschev <i...@altlinux.org>: The issue https://bugs.python.org/msg314475 has arisen for tuples (but not for lists, as in the example there) in 2.7.14 for me. How should we fix it in a better way? This bug is not reproducible in python 3.5.4. [builder@loc

[issue1704621] interpreter crash when multiplying large lists

2018-03-27 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: New issue filed: https://bugs.python.org/issue33153 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.o

[issue33153] interpreter crash when multiplying large tuples

2018-03-27 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: I meant the old issue https://bugs.python.org/issue1704621 . -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue1704621] interpreter crash when multiplying large lists

2018-03-26 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: Hi! This is broken for tuples (but not for lists, as in the example here) in 2.7.14 for me. Should we reopen this issue and fix it better? [builder@localhost ~]$ python Python 2.7.14 (default, Nov 7 2017, 17:07:17) [GCC

[issue6083] Reference counting bug in PyArg_ParseTuple and PyArg_ParseTupleAndKeywords

2018-03-22 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: And will the next call be effective (do anything), if we have already set the limit with the testing call? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.pytho

[issue6083] Reference counting bug in PyArg_ParseTuple and PyArg_ParseTupleAndKeywords

2018-03-22 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: Thanks! I also thought about this simplest way. What about this: diff --git a/Python/Lib/test/test_resource.py b/Python/Lib/test/test_resource.py index de29d3b..bec4440 100644 --- a/Python/Lib/test/test_resource.py +++ b/Python/Li

[issue6083] Reference counting bug in PyArg_ParseTuple and PyArg_ParseTupleAndKeywords

2018-03-22 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: >>> import resource >>> resource.getrlimit(resource.RLIMIT_CPU) (7200, 7260) -- ___ Python tracker <rep...@bugs.python.org> <

[issue6083] Reference counting bug in PyArg_ParseTuple and PyArg_ParseTupleAndKeywords

2018-03-22 Thread Ivan Zakharyaschev
Ivan Zakharyaschev <i...@altlinux.org> added the comment: > New changeset a4c85f9b8f58 by Serhiy Storchaka in branch '2.7': Issue #6083: Fix multiple segmentation faults occured when PyArg_ParseTuple http://hg.python.org/cpython/rev/a4c85f9b8f58 This test has a problem: though

[issue26912] test/test_email/torture_test.py (and test_asian_codecs.py) has a broken import

2016-05-02 Thread Ivan Zakharyaschev
New submission from Ivan Zakharyaschev: (An issue similar to http://bugs.python.org/issue26911 , but with a different source file from the tests) Lib/test/test_email/torture_test.py:15:from email.test.test_email import TestEmailBase should be: from test.test_email import TestEmailBase