[issue45860] Mutithread leads to Illegal instruction crashing CPython
Change by Xinmeng Xia : -- title: UnboundLocalError leads to Illegal instruction crashing CPython -> Mutithread leads to Illegal instruction crashing CPython ___ Python tracker <https://bugs.python.org/issue45860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45860] UnboundLocalError leads to Illegal instruction crashing CPython
Xinmeng Xia added the comment: A simpler example to reproduce it: test.py import threading import ctypes from test import test_code def test_free_different_thread(): f = test_code.CoExtra().get_func() class ThreadTest(threading.Thread): def __init__(CoExtra, f, test): f.test = f test_code.SetExtra(f.__code__, test_code.FREE_INDEX, ctypes.c_voidp(500)) tt = ThreadTest(f, f) test_code.CoExtra().assertEqual(test_code.LAST_FREED, 500) test_free_different_thread() Just run test.py on Ubuntu 18.04 and you can observe the crash. version of Python: Python3.11.0a4 -- ___ Python tracker <https://bugs.python.org/issue45860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46211] Recursively calling makepasv() finally leads to core dumped.
New submission from Xinmeng Xia : See the following 'test.py', we call client.makepasv() in socket, and then create_connection. Recursively calling makepasv() finally leads to core dumped. System: Python 3.10.1, 3.11.0a3 ,master on Ubuntu 18.04 Reproduce step: 1. executing "python test.py" 2. If only TimeoutError is observed, just executing this code again. Maybe after 4 or 5 times, this program crashes Python interpreter. test.py === import socket from test.test_ftplib import TestFTPClass,TIMEOUT def test_makepasv(): host, port = TestFTPClass.client.makepasv() conn = socket.create_connection((test_makepasv(), host), timeout=TIMEOUT) conn.close() === Error Message: --- Exception in thread Thread-1: Traceback (most recent call last): File "/home/xxm/Desktop/compilers/cpython-main12-31/Lib/asyncore.py", line 90, in read obj.handle_read_event() ^^^ File "/home/xxm/Desktop/compilers/cpython-main12-31/Lib/asyncore.py", line 427, in handle_read_event Traceback (most recent call last): . File "/home/xxm/Desktop/compilers/cpython-main12-31/Lib/test/test_ftplib.py", line 298, in run return self._sock.recv_into(b) ^^^ TimeoutError: timed out Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name=''> at interpreter shutdown, possibly due to daemon threads Python runtime state: finalizing (tstate=0x556df3cfbe30) Current thread 0x7fb82ce69080 (most recent call first): Extension modules: _testcapi (total: 1) Aborted (core dumped) - -- components: Library (Lib) messages: 409408 nosy: xxm priority: normal severity: normal status: open title: Recursively calling makepasv() finally leads to core dumped. type: crash versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46115] Interrupting subprocess.popen in recursive calls by KeyboardInterrupt causes Fatal Python error.
New submission from Xinmeng Xia : Popen works when stdio fds are available. However, when interrupting popen in a recursive function call. The Python interpreter reports a Fatal Python error. test.py import subprocess import os import sys def test_small_errpipe_write_fd(): new_stdout = os.dup(1) try: os.close(1) subprocess.Popen([sys.executable, '-c', "print('AssertionError:0:CLOEXEC failure.')"]).wait() finally: os.dup2(new_stdout, 0) os.dup2(new_stdout, 1) test_small_errpipe_write_fd() test_small_errpipe_write_fd() === Reported message: - xxm@xxm:~$ 'cpython-main/python' '/home/xxm/Desktop/test/test.py' ^CFatal Python error: init_import_site: Failed to import the site module Python runtime state: initialized Traceback (most recent call last): File "/home/xxm/Desktop/compilers/cpython-main/Lib/site.py", line 73, in import os ^ File "/home/xxm/Desktop/compilers/cpython-main/Lib/os.py", line 29, in from _collections_abc import _check_methods ^^^ File "/home/xxm/Desktop/compilers/cpython-main/Lib/_collections_abc.py", line 1015, in class Sequence(Reversible, Collection): ^^^ File "/home/xxm/Desktop/compilers/cpython-main/Lib/abc.py", line 106, in __new__ cls = super().__new__(mcls, name, bases, namespace, **kwargs) ^^^ KeyboardInterrupt --- Reproduce step: 1. run test.py in the console 2. use "Ctrl C" to interrupt the program If typing a "Ctrl C", the program does not stop and no error is reported. Just type "Ctrl C" constantly. Sometimes, it need 5 or 6 "Ctrl C" to reproduce this bug. verson of Python: Python 3.11.0a2+ (main, Nov 26 2021, 18:38:48) [GCC 7.5.0] on linux (it also crashes Python 3.6.15, 3.7.12,3.8.12) -- components: Interpreter Core messages: 408772 nosy: xxm priority: normal severity: normal status: open title: Interrupting subprocess.popen in recursive calls by KeyboardInterrupt causes Fatal Python error. type: crash versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45860] UnboundLocalError leads to Illegal instruction crashing CPython
New submission from Xinmeng Xia : The following code can lead to a crash and report Illegal instruction (core dumped)(few times) or Trace/breakpoint trap (core dumped) (very few times) or Segmentation fault (core dumped) (most times) on Python 3.11. test_free_different_thread.py import inspect import sys import threading import unittest import weakref import ctypes from test.support import run_doctest, run_unittest, cpython_only, check_impl_detail import _testcapi from types import FunctionType from test import test_code import test_code def test_free_different_thread(): f = CoExtra.get_func() class ThreadTest(threading.Thread): def __init__(CoExtra, f, test): super().__init__() CoExtra.f = CoExtra CoExtra.test = test def run(CoExtra): del CoExtra.f CoExtra.test.assertEqual(test_code.LAST_FREED, 500) test_code.SetExtra(f.__code__, test_code.FREE_INDEX, ctypes.c_voidp(500)) f = ThreadTest(CoExtra, f) del tt tt.start() tt.join() CoExtra.assertEqual(test_code.LAST_FREED, 500) CoExtra = test_code.CoExtra() test_free_different_thread() = - Traceback (most recent call last): File "/home/xxm/Desktop/test_free_different_thread.py", line 33, in test_free_different_thread() File "/home/xxm/Desktop/test_free_different_thread.py", line 28, in test_free_different_thread del tt ^^ UnboundLocalError: cannot access local variable 'tt' where it is not associated with a value Illegal instruction (core dumped)/Trace/breakpoint trap (core dumped)/Segmentation fault (core dumped) Version: python 3.9, python 3.10, python 3.11 on ubuntu 16.04 Reproduce step: 1.download test_code.py and place test_free_different_thread.py and test_code in a same directory. 2. run with "python test_free_different_thread.py" The test_code.py is from cpython' test. We can also annotate "import test_code" and run test_free_different_thread.py directly. But it seems that Illegal instruction and Trace/breakpoint trap cannot be reproduced. -- components: Interpreter Core files: test_code.py messages: 406740 nosy: xxm priority: normal severity: normal status: open title: UnboundLocalError leads to Illegal instruction crashing CPython type: crash versions: Python 3.11 Added file: https://bugs.python.org/file50455/test_code.py ___ Python tracker <https://bugs.python.org/issue45860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45813] Importing asyncio after deleting a coroutine object and before cleaning it up leads to crashing on Python3.11
Xinmeng Xia added the comment: Thanks for testing it. Maybe it only crashes on Unix-like operating systems. I also try it on MacOS 11.6.1. with -i to ensure that python survives running the test code. On MacOS, it reports the following crashing information: --- xxm$ Python-3.11.0a2/python.exe -i test.py test.py:5: RuntimeWarning: coroutine 'f' was never awaited del f RuntimeWarning: Enable tracemalloc to get the object allocation traceback Segmentation fault: 11 -- ___ Python tracker <https://bugs.python.org/issue45813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45826] unittest.assertRaisesRegex is broken in Python 3.11 and leading to crashing if tested regex does not match name.
New submission from Xinmeng Xia : In Python 3.11, unittest.assertRaisesRegex is broken and leading to crashing if tested regex does not match name. See the following example: test.py = import unittest class uTest(unittest.TestCase): pass uTest = uTest() with uTest.assertRaisesRegex(Exception, 'aaa'): aab = Output in Python3.9.2, 3.10: -- NameError: name 'aab' is not defined During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/xxm/Desktop/test.py", line 29, in aab File "/usr/local/python310/lib/python3.10/unittest/case.py", line 239, in __exit__ self._raiseFailure('"{}" does not match "{}"'.format( File "/usr/local/python310/lib/python3.10/unittest/case.py", line 163, in _raiseFailure raise self.test_case.failureException(msg) AssertionError: "aaa" does not match "name 'aab' is not defined -- Actual output in Python3.11.0a1,Python3.11.0a2: Segmentation fault (core dumped) System: Ubuntu 16.04 -- components: Library (Lib) messages: 406445 nosy: xxm priority: normal severity: normal status: open title: unittest.assertRaisesRegex is broken in Python 3.11 and leading to crashing if tested regex does not match name. type: crash versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45813] Importing asyncio after deleting a coroutine object and before cleaning it up leads to crashing on Python3.11
New submission from Xinmeng Xia : The following crashing can only reproduce on Python3.11. In this case, we import "asyncio" after deleting a coroutine object and before cleaning it up, leading to crashing. test.py === async def f(): pass f = f() frame = f.cr_frame del f import asyncio frame.clear() == >>>Python3.11 -Werror test.py Exception ignored in: Traceback (most recent call last): File "python311/Lib/warnings.py", line 506, in _warn_unawaited_coroutine warn(msg, category=RuntimeWarning, stacklevel=2, source=coro) ^ RuntimeWarning: coroutine 'f' was never awaited Segmentation fault (core dumped) Version: Python 3.11.0a2+ on Ubuntu 16.04 -- components: asyncio messages: 406388 nosy: asvetlov, xxm, yselivanov priority: normal severity: normal status: open title: Importing asyncio after deleting a coroutine object and before cleaning it up leads to crashing on Python3.11 type: crash versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45707] Variable reassginment triggers incorrect behaviors of locals()
New submission from Xinmeng Xia : Normally after executing a piece of code in a function, locals() should contain the local variables and these variables can be reassigned next. In the following code, "attr" should be found in locals(). Actually, it can not be found in either locals() or globals() after executing code "attr = 1". This program triggers a keyError. I think something wrong during handling locals(). def foo(): exec("attr = 1") a = locals()['attr'] attr = 2 foo() Reported Error: Traceback (most recent call last): File "", line 1, in File "", line 3, in foo KeyError: 'attr' Expected output: This test program should work well. The value of a is 1 and the value of attr is 2 after execution. No error is reported. Python version: python3.10, Ubuntu 16.04 -- components: Interpreter Core messages: 405660 nosy: xxm priority: normal severity: normal status: open title: Variable reassginment triggers incorrect behaviors of locals() type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45707> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44720] Finding string in iteratively deleted object cause segfault
New submission from Xinmeng Xia : This piece of code is originally from https://github.com/python/cpython/tree/main/Lib/test/test_weakref.py. In function test_proxy_iter(), we change the original data dependency and then this generated test case (see the following "test.py") crashes Python. Crashing Python version: 3.6-master(3.11.0a0) test.py = import weakref def test_proxy_iter(): obj = None class MyObj: def __iter__(a): nonlocal obj del obj - return NotImplemented + return p obj = MyObj() - p = weakref.proxy(obj) + p = weakref.proxy(TypeError) - 'blech' in p + 'blech' in obj test_proxy_iter() === system: ubuntu 16.04 crash: segmentation fault -- components: Interpreter Core files: test.py messages: 398029 nosy: xxm priority: normal severity: normal status: open title: Finding string in iteratively deleted object cause segfault type: crash versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file50171/test.py ___ Python tracker <https://bugs.python.org/issue44720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44719] Incorrect callable object crashes Python 3.11.0a0
New submission from Xinmeng Xia : This program can trigger "Aborted (core dumped)" on Python 3.9.0, Python 3.8.0, Python3.10.0a2. It trigger " segmentation fault" on the master (Python 3.11.0a0). == import weakref class Object: def __init__(self, arg): self.arg = arg def test_set_callback_attribute(): x = Object(1) callback = lambda ref: None callback = weakref.ref(callback, x) with test_set_callback_attribute(): pass test_set_callback_attribute() == Crashes on the master (Python 3.11.0a0) . Traceback (most recent call last): File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 26, in test_set_callback_attribute callback = weakref.ref(callback, x) TypeError: 'Object' object is not callable Exception ignored in: <__main__.Object object at 0x7f3e2d56ca90> Traceback (most recent call last): File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 26, in test_set_callback_attribute Segmentation fault (core dumped) -- Crashes on the older version of Python --- File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute File "/home/xxm/Desktop/IFuzzer/bugs/CPython/IFuzzer/test_weakref/test_set_callback_attribute__1.py", line 27 in test_set_callback_attribute ... Aborted (core dumped) --- System: Ubuntu 16.04 -- components: Interpreter Core messages: 398028 nosy: xxm priority: normal severity: normal status: open title: Incorrect callable object crashes Python 3.11.0a0 type: crash versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44719> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44718] Incorrect arguments in function select() cause segfault
New submission from Xinmeng Xia : The following program can trigger segfault on all releases of Python. I think it may be caused by incorrect arguments. Version of Python: 3.6 - master(3.11.0a0) system: ubuntu 16.04 test.py import select def test_select_mutated(): a = [] class F: def fileno(a): del test_select_mutated()[-1] return sys.__stdout__.fileno() a[:] = [F()] * 10 select.select([], a, []), ([], a[:5], []) test_select_mutated() output: - xxm@xxm:~$ '/home/xxm/Desktop/compiler/cpython-main/python' test.py Segmentation fault (core dumped) - -- components: Interpreter Core messages: 398027 nosy: xxm priority: normal severity: normal status: open title: Incorrect arguments in function select() cause segfault type: crash versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42813] Extra spaces cause unexpected EOF error in "compile" function with mode "single"
Xinmeng Xia added the comment: Program like following reports error on CPython(master branch), however this program can work well on PyPy. I think this is a bug in CPython == string =""" if 1: print("hello") """ compile(string, "", "single") == Traceback (most recent call last): File "/home/xxm/Desktop/IFuzzer/test/test1.py", line 304, in compile(string, "", "single") ^ File "", line 4 SyntaxError: unexpected EOF while parsing -- ___ Python tracker <https://bugs.python.org/issue42813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42889] Incorrect behavior after ast node visits
Xinmeng Xia added the comment: This crash cannot be reproduced again on the master branch of CPython. It seems that this bug has been fixed. Should we close this issue and mark it as "fixed"? -- ___ Python tracker <https://bugs.python.org/issue42889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43909] Fuzz dis module and find crashes for dis.dis(), dis.get_instructions() dis.show_code()
New submission from Xinmeng Xia : We write a fuzz tool to fuzz Python standard libraries, and find three crashes: dis.dis(), dis.get_instructions() dis.show_code() in dis module. dis.dis() == xiaxinmeng:~ xiaxinmeng$ python3.10 Python 3.10.0a3 (v3.10.0a3:8bae2a958e, Dec 7 2020, 15:31:51) [Clang 12.0.0 (clang-1200.0.32.27)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import dis >>> dis.dis("s%-yPdrns"*100) Segmentation fault: 11 = dis.get_instructions() = Python 3.10.0a3 (v3.10.0a3:8bae2a958e, Dec 7 2020, 15:31:51) [Clang 12.0.0 (clang-1200.0.32.27)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import dis >>> dis.get_instructions("c/f/x"*100) Segmentation fault: 11 == dis.show_code() === Python 3.10.0a3 (v3.10.0a3:8bae2a958e, Dec 7 2020, 15:31:51) [Clang 12.0.0 (clang-1200.0.32.27)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import dis >>> dis.show_code("G/7/K"*100) Segmentation fault: 11 -- components: Library (Lib) messages: 391574 nosy: xxm priority: normal severity: normal status: open title: Fuzz dis module and find crashes for dis.dis(), dis.get_instructions() dis.show_code() type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43740] Long paths in imp.load_dynamic() lead to segfault
New submission from Xinmeng Xia : Long paths as arguments of imp.load_dynamic() lead to interpreter crashes. Crash example = Python 3.10.0a2 (default, Nov 24 2020, 14:18:46) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.load_dynamic('',"abs/"*1000) Segmentation fault (core dumped) == Environment: Ubuntu 16.04, Python 3.92, Python 3.10.0a2 Mac OS Big Sur 11.2.3, Python 3.91, Python 3.10.0a2 Testing with gdb - $gdb ./python (gdb) run Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.load_dynamic('','abs/'*1) Program received signal SIGSEGV, Segmentation fault. memcpy () at ../sysdeps/x86_64/multiarch/../memcpy.S:272 272 ../sysdeps/x86_64/multiarch/../memcpy.S: No such file or directory. Testing with valgrind - xxm@xxm-System-Product-Name:~$ PYTHONMALLOC=malloc_debug valgrind '/home/xxm/Desktop/apifuzz/Python-3.10.0a6/python' ==4923== Memcheck, a memory error detector ==4923== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==4923== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==4923== Command: /home/xxm/Desktop/apifuzz/Python-3.10.0a6/python ==4923== Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.dgettext('abs'*10,'') '' >>> import imp :1: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses >>> imp.load_dynamic('','abs/'*1) ==4923== Warning: set address range perms: large range [0x8037040, 0x1fdaf489) (undefined) ==4923== Warning: set address range perms: large range [0x1fdb0040, 0x37b28479) (undefined) ==4923== Warning: set address range perms: large range [0x37b29040, 0x4f8a1441) (undefined) ==4923== Warning: set address range perms: large range [0x37b29028, 0x4f8a1459) (noaccess) ==4923== Warning: set address range perms: large range [0x59eb3040, 0x71c2b460) (undefined) ==4923== Warning: client switching stacks? SP change: 0x1ffeffe460 --> 0x1fe7286028 ==4923== to suppress, use: --max-stackframe=40056 or greater ==4923== Invalid write of size 8 ==4923== at 0x401513F: _dl_open (dl-open.c:701) ==4923== Address 0x1fe7286028 is on thread 1's stack ==4923== ==4923== ==4923== Process terminating with default action of signal 11 (SIGSEGV) ==4923== Access not within mapped region at address 0x1FE7286028 ==4923== at 0x401513F: _dl_open (dl-open.c:701) ==4923== If you believe this happened as a result of a stack ==4923== overflow in your program's main thread (unlikely but ==4923== possible), you can try to increase the size of the ==4923== main thread stack using the --main-stacksize= flag. ==4923== The main thread stack size used in this run was 8388608. ==4923== Invalid write of size 8 ==4923== at 0x4A2867A: _vgnU_freeres (vg_preloaded.c:57) ==4923== Address 0x1fe7286020 is on thread 1's stack ==4923== ==4923== ==4923== Process terminating with default action of signal 11 (SIGSEGV) ==4923== Access not within mapped region at address 0x1FE7286020 ==4923== at 0x4A2867A: _vgnU_freeres (vg_preloaded.c:57) ==4923== If you believe this happened as a result of a stack ==4923== overflow in your program's main thread (unlikely but ==4923== possible), you can try to increase the size of the ==4923== main thread stack using the --main-stacksize= flag. ==4923== The main thread stack size used in this run was 8388608. ==4923== ==4923== HEAP SUMMARY: ==4923== in use at exit: 1,205,374,369 bytes in 36,250 blocks ==4923== total heap usage: 96,421 allocs, 60,171 frees, 1,616,393,081 bytes allocated ==4923== ==4923== LEAK SUMMARY: ==4923== definitely lost: 0 bytes in 0 blocks ==4923== indirectly lost: 0 bytes in 0 blocks ==4923== possibly lost: 805,237,234 bytes in 35,439 blocks ==4923== still reachable: 400,137,135 bytes in 811 blocks ==4923== suppressed: 0 bytes in 0 blocks ==4923== Rerun with --leak-check=full to see details of leaked memory ==4923== ==4923== For lists of detected and suppressed errors, rerun with: -s ==4923== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) Segmentation fault (core dumped) -- components: Library (Lib) messages: 390284 nosy: xxm pr
[issue43664] Long computations in pdb.run() lead to segfault
Xinmeng Xia added the comment: pdb.run() seems crashing different positions of Python (Python/ast_opt.c:488 for pdb.run, Python/ast_opt.c:494 for compile()). But the commit 364d0d20f924071b749e5a889eca22628f4892a3, PR 23744, bpo-42609 for compile() also fix this bug in pdb.run(). Should we close this issue and mark it as fixed? $ gdb ./python (gdb) run Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> compile("1+2" * 100, "-", "exec") Program received signal SIGSEGV, Segmentation fault. 0x0063aedc in astfold_expr (node_=0xf5707d0, ctx_=0x76282450, state=0x7fffd608) at Python/ast_opt.c:494 494 CALL(astfold_expr, expr_ty, node_->v.BinOp.left); (gdb) run Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import pdb >>> pdb.run("1+2"*100) Program received signal SIGSEGV, Segmentation fault. 0x0063ac8f in astfold_expr (node_=0xf59b810, ctx_=0x761f7c30, state=0x7fffd1c8) at Python/ast_opt.c:488 488 { (gdb) $gdb '/home/xxm/Downloads/cpython-364d0d20f924071b749e5a889eca22628f4892a3/python' (gdb) run Python 3.10.0a3+ (default, Apr 6 2021, 11:24:27) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> compile("1+2" * 100, "-", "exec") Traceback (most recent call last): File "", line 1, in RecursionError: maximum recursion depth exceeded during compilation >>> import pdb >>> pdb.run("1+2"*100) Traceback (most recent call last): File "", line 1, in File "/home/xxm/Downloads/cpython-364d0d20f924071b749e5a889eca22628f4892a3/Lib/pdb.py", line 1597, in run Pdb().run(statement, globals, locals) File "/home/xxm/Downloads/cpython-364d0d20f924071b749e5a889eca22628f4892a3/Lib/bdb.py", line 577, in run cmd = compile(cmd, "", "exec") RecursionError: maximum recursion depth exceeded during compilation -- ___ Python tracker <https://bugs.python.org/issue43664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43599] Setting long domain of locale.dgettext() crashes Python interpreter
Xinmeng Xia added the comment: Attached testing results of gdb and valgrind. (No error is reported for locale.dgettext('abs'*10,'')) $gdb ./python (gdb) run >>> locale.dgettext('abs'*1000,'') Program received signal SIGSEGV, Segmentation fault. __dcigettext ( domainname=domainname@entry=0xadb030 "absabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsabsab"..., msgid1=msgid1@entry=0x77fc09a0 "", msgid2=msgid2@entry=0x0, plural=plural@entry=0, n=n@entry=0, category=category@entry=5) at dcigettext.c:675 675 dcigettext.c: No such file or directory. (gdb) valgrind ~$ PYTHONMALLOC=malloc_debug valgrind python Memcheck, a memory error detector ==4870== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==4870== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==4870== Command: /home/xxm/Desktop/apifuzz/Python-3.10.0a6/python ==4870== Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> locale.dgettext('abs'*1000,'') Traceback (most recent call last): File "", line 1, in NameError: name 'locale' is not defined >>> import locale >>> locale.dgettext('abs'*1000,'') ==4870== Warning: client switching stacks? SP change: 0x1ffefff5c0 --> 0x1ffd363220 ==4870== to suppress, use: --max-stackframe=3032 or greater ==4870== Invalid write of size 8 ==4870==at 0x5797E88: __dcigettext (dcigettext.c:675) ==4870== Address 0x1ffd363218 is on thread 1's stack ==4870== ==4870== ==4870== Process terminating with default action of signal 11 (SIGSEGV) ==4870== Access not within mapped region at address 0x1FFD363218 ==4870==at 0x5797E88: __dcigettext (dcigettext.c:675) ==4870== If you believe this happened as a result of a stack ==4870== overflow in your program's main thread (unlikely but ==4870== possible), you can try to increase the size of the ==4870== main thread stack using the --main-stacksize= flag. ==4870== The main thread stack size used in this run was 8388608. ==4870== Invalid write of size 8 ==4870==at 0x4A2867A: _vgnU_freeres (vg_preloaded.c:57) ==4870== Address 0x1ffd363210 is on thread 1's stack ==4870== ==4870== ==4870== Process terminating with default action of signal 11 (SIGSEGV) ==4870== Access not within mapped region at address 0x1FFD363210 ==4870==at 0x4A2867A: _vgnU_freeres (vg_preloaded.c:57) ==4870== If you believe this happened as a result of a stack ==4870== overflow in your program's main thread (unlikely but ==4870== possible), you can try to increase the size of the ==4870== main thread stack using the --main-stacksize= flag. ==4870== The main thread stack size used in this run was 8388608. ==4870== ==4870== HEAP SUMMARY: ==4870== in use at exit: 35,310,749 bytes in 35,706 blocks ==4870== total heap usage: 87,221 allocs, 51,515 frees, 44,733,752 bytes allocated ==4870== ==4870== LEAK SUMMARY: ==4870==definitely lost: 0 bytes in 0 blocks ==4870==indirectly lost: 0 bytes in 0 blocks ==4870== possibly lost: 35,173,680 bytes in 34,899 blocks ==4870==still reachable: 137,069 bytes in 807 blocks ==4870== suppressed: 0 bytes in 0 blocks ==4870== Rerun with --leak-check=full to see details of leaked memory ==4870== ==4870== For lists of detected and suppressed errors, rerun with: -s ==4870== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) Segmentation fault (core dumped) -- ___ Python tracker <https://bugs.python.org/issue43599> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43549] Outdated descriptions for configuring valgrind.
Change by Xinmeng Xia : -- type: behavior -> enhancement ___ Python tracker <https://bugs.python.org/issue43549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43664] Long computations in pdb.run() lead to segfault
New submission from Xinmeng Xia : Long computations in pdb.run() lead to interpreter crashes. Crash example === Python 3.9.2 (default, Mar 12 2021, 15:08:35) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import pdb >>> pdb.run("1+2"*100) Segmentation fault (core dumped) === Environment: Ubuntu 16.04, Python 3.9.2, Python 3.10.0a6 Mac OS Big Sur 11.2.3, Python 3.91, Python 3.10.0a2 -- components: Library (Lib) messages: 389789 nosy: xxm priority: normal severity: normal status: open title: Long computations in pdb.run() lead to segfault type: crash versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43663] Python interpreter works abnormally after interrupting logging.config.fileConfig()
New submission from Xinmeng Xia : Python interpreter cannot work well and report errors after interrupting logging.config.fileConfig() Reproduce step: 1. type python3 in console 2. type import logging.config; logging.config.fileConfig({2,2,'sdf'},'') 3. ctrl C 4. type 1/0 --- Python 3.9.2 (default, Mar 12 2021, 15:08:35) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 1/0 Traceback (most recent call last): File "", line 1, in ZeroDivisionError: division by zero >>> import logging.config >>> logging.config.fileConfig({2,2,'sdf'},'') ^C>>> 1/0 >>> Expected result: 1/0 will return a ZeroDivisionError after interrupting " logging.config.fileConfig({2,2,'sdf'},'') " Actual result: Nothing output Python 3.9.2, Ubuntu 16.04 -- components: Library (Lib) messages: 389788 nosy: xxm priority: normal severity: normal status: open title: Python interpreter works abnormally after interrupting logging.config.fileConfig() type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43611] Function tcflow() in module termios can not be interupted when the second argument is 0
New submission from Xinmeng Xia : In Ubuntu 16.04, termios.tcflow(1, 0) cannot be interrupted by Ctrl C, Ctrl D, Ctrl Z. It work well on mac OS. (Ctrl C can interrupt it on Mac OS). Reproduce: 1. type 'python3' in command console; 2. type ‘import termios; termios.tcflow(1, 0)’ 3. try “ctrl C”, “Ctrl D”, “Ctrl Z” = xxm@xxm-System-Product-Name:~$ '/home/xxm/Desktop/apifuzz/Python-3.10.0a6/python' Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import termios >>> termios.tcflow(1, 0) = Expected result: this function can be interrupted or stopped by Ctrl C, Ctrl D, Ctrl Z. Actual result: No response for Ctrl C, Ctrl D, Ctrl Z System Ubuntu 16.04 -- components: Library (Lib) messages: 389436 nosy: xxm priority: normal severity: normal status: open title: Function tcflow() in module termios can not be interupted when the second argument is 0 type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43610] Ctrl C makes interpreter exit
New submission from Xinmeng Xia : Python interpreter will exit when using Ctrl C to interrupt some Python module functions with read operations. e.g. sndhdr.what(0), pdb.find_function('abs/'*10,False), mimetypes.read_mime_types(0). This is not the expected behavior. Ctrl C is to raise a KeyboardInterrupt, it should not crash Python and make interpreter exit. Reproduce: 1. type 'python3' in command console; 2. type 'import sndhdr;sndhdr.what(0)' 3. type ctrl C Expected behavior: type ctrl c, raise a KeyboardInterrupt, Python does not exit. xxm@xxm-System-Product-Name:~$ python Python 3.9.2 (default, Mar 12 2021, 15:08:35) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> KeyboardInterrupt >>> Unexpected behavior: type ctrl c, raise a KeyboardInterrupt, Python exits. === xxm@xxm-System-Product-Name:~$ python Python 3.9.2 (default, Mar 12 2021, 15:08:35) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sndhdr;sndhdr.what(0) ^CTraceback (most recent call last): File "", line 1, in File "/home/xxm/Desktop/apifuzz/Python-3.9.2/Lib/sndhdr.py", line 54, in what res = whathdr(filename) File "/home/xxm/Desktop/apifuzz/Python-3.9.2/Lib/sndhdr.py", line 61, in whathdr h = f.read(512) KeyboardInterrupt >>> xxm@xxm-System-Product-Name:~$ === System: Ubuntu 16.04 -- components: Library (Lib) messages: 389431 nosy: xxm priority: normal severity: normal status: open title: Ctrl C makes interpreter exit type: crash versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43599] Setting long domain of locale.dgettext() crashes Python interpreter
New submission from Xinmeng Xia : Setting the first argument of locale.dgettext() long string, Python interpreter crashes. == Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import locale;locale.dgettext('abs'*1000,'') Segmentation fault (core dumped) == System: Ubuntu 16.04 BTW, the api of module locale seems to be inconsistent between Ubuntu and Mac OS. E.g. there is no dgettext() for Python on Mac OS. -- components: Library (Lib) messages: 389363 nosy: xxm priority: normal severity: normal status: open title: Setting long domain of locale.dgettext() crashes Python interpreter type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43599> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43587] Long string arguments cause nis.map() segfault
New submission from Xinmeng Xia : nis.maps() with long string argument will lead to segfault of interpreter. See the following example: = Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import nis; >>> nis.maps('abs/'*1000) Segmentation fault (core dumped) = System: ubuntu 16.04 -- components: Library (Lib) messages: 389280 nosy: xxm priority: normal severity: normal status: open title: Long string arguments cause nis.map() segfault type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43509] CFunctionType object should be hashable in Python
Change by Xinmeng Xia : -- type: compile error -> enhancement ___ Python tracker <https://bugs.python.org/issue43509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43549] Outdated descriptions for configuring valgrind.
New submission from Xinmeng Xia : At line 12-20, cpython/Misc/README.valgrind, the descriptions are out of date. File "Objects/obmalloc.c" does not contain Py_USING_MEMORY_DEBUGGER any more since Python 3.6. The descriptions should be modified for Python 3.6-3.10 Attached line 12-20, cpython/Misc/README.valgrind: = If you don't want to read about the details of using Valgrind, there are still two things you must do to suppress the warnings. First, you must use a suppressions file. One is supplied in Misc/valgrind-python.supp. Second, you must do one of the following: * Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c, then rebuild Python * Uncomment the lines in Misc/valgrind-python.supp that suppress the warnings for PyObject_Free and PyObject_Realloc = -- assignee: docs@python components: Documentation messages: 389052 nosy: docs@python, xxm priority: normal severity: normal status: open title: Outdated descriptions for configuring valgrind. type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43537] interpreter crashes when handling long text in input()
Change by Xinmeng Xia : -- title: nterpreter crashes when handling long text in input() -> interpreter crashes when handling long text in input() ___ Python tracker <https://bugs.python.org/issue43537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43537] nterpreter crashes when handling long text in input()
New submission from Xinmeng Xia : When the argument of input() is very long text, the interpreter crashes. This bug can be reproduced Python 3.9.2 and Python 2.7.18 on Ubuntu 3.9.2 with GCC7.5.0. I try to reproduce this bug on other version of Python and Operating System, but it fails. This bug seems to have a connection with the version of GCC. Python 3.9.2 (default, Mar 12 2021, 15:08:35) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> input([1,2]*1) *** Error in `/home/xxm/Desktop/apifuzz/Python-3.9.2/python': realloc(): invalid next size: 0x0135fd40 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x777f5)[0x7f714431b7f5] /lib/x86_64-linux-gnu/libc.so.6(+0x834da)[0x7f71443274da] /lib/x86_64-linux-gnu/libc.so.6(realloc+0x199)[0x7f71443288a9] /lib/x86_64-linux-gnu/libreadline.so.6(xrealloc+0xe)[0x7f71446a1ffe] /lib/x86_64-linux-gnu/libreadline.so.6(rl_redisplay+0x125f)[0x7f714469451f] /lib/x86_64-linux-gnu/libreadline.so.6(readline_internal_setup+0xb0)[0x7f7144681340] /lib/x86_64-linux-gnu/libreadline.so.6(+0x2a4ac)[0x7f71446984ac] /home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x5d60b2] /home/xxm/Desktop/apifuzz/Python-3.9.2/python(PyOS_Readline+0x116)[0x5da536] /home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x648495] /home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x613f26] /home/xxm/Desktop/apifuzz/Python-3.9.2/python(_PyEval_EvalFrameDefault+0x54e2)[0x4267a2] /home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x4fa3e9] /home/xxm/Desktop/apifuzz/Python-3.9.2/python(PyEval_EvalCode+0x36)[0x4fa746] /home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x543adf] /home/xxm/Desktop/apifuzz/Python-3.9.2/python[0x546d82] /home/xxm/Desktop/apifuzz/Python-3.9.2/python(PyRun_InteractiveLoopFlags+0x8e)[0x54704e] /home/xxm/Desktop/apifuzz/Python-3.9.2/python(PyRun_AnyFileExFlags+0x3c)[0x5478fc] /home/xxm/Desktop/apifuzz/Python-3.9.2/python(Py_RunMain+0x8d7)[0x42b1e7] /home/xxm/Desktop/apifuzz/Python-3.9.2/python(Py_BytesMain+0x56)[0x42b586] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f71442c4840] /home/xxm/Desktop/apifuzz/Python-3.9.2/python(_start+0x29)[0x42a289] === Memory map: 0040-00762000 r-xp 08:07 7740578 /home/xxm/Desktop/apifuzz/Python-3.9.2/python 00961000-00962000 r--p 00361000 08:07 7740578 /home/xxm/Desktop/apifuzz/Python-3.9.2/python 00962000-0099a000 rw-p 00362000 08:07 7740578 /home/xxm/Desktop/apifuzz/Python-3.9.2/python 0099a000-009be000 rw-p 00:00 0 012dc000-013ce000 rw-p 00:00 0 [heap] 7f713c00-7f713c021000 rw-p 00:00 0 7f713c021000-7f714000 ---p 00:00 0 7f71439b5000-7f71439cc000 r-xp 08:07 1966109 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f71439cc000-7f7143bcb000 ---p 00017000 08:07 1966109 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f7143bcb000-7f7143bcc000 r--p 00016000 08:07 1966109 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f7143bcc000-7f7143bcd000 rw-p 00017000 08:07 1966109 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f7143bf-7f714407b000 r--p 08:07 4326136 /usr/lib/locale/locale-archive 7f714407b000-7f71440a r-xp 08:07 1970777 /lib/x86_64-linux-gnu/libtinfo.so.5.9 7f71440a-7f714429f000 ---p 00025000 08:07 1970777 /lib/x86_64-linux-gnu/libtinfo.so.5.9 7f714429f000-7f71442a3000 r--p 00024000 08:07 1970777 /lib/x86_64-linux-gnu/libtinfo.so.5.9 7f71442a3000-7f71442a4000 rw-p 00028000 08:07 1970777 /lib/x86_64-linux-gnu/libtinfo.so.5.9 7f71442a4000-7f7144464000 r-xp 08:07 1966308 /lib/x86_64-linux-gnu/libc-2.23.so 7f7144464000-7f7144664000 ---p 001c 08:07 1966308 /lib/x86_64-linux-gnu/libc-2.23.so 7f7144664000-7f7144668000 r--p 001c 08:07 1966308 /lib/x86_64-linux-gnu/libc-2.23.so 7f7144668000-7f714466a000 rw-p 001c4000 08:07 1966308 /lib/x86_64-linux-gnu/libc-2.23.so 7f714466a000-7f714466e000 rw-p 00:00 0 7f714466e000-7f71446ab000 r-xp 08:07 1970756 /lib/x86_64-linux-gnu/libreadline.so.6.3 7f71446ab000-7f71448ab000 ---p 0003d000 08:07 1970756 /lib/x86_64-linux-gnu/libreadline.so.6.3 7f71448ab000-7f71448ad000 r--p 0003d000 08:07 1970756 /lib/x86_64-linux-gnu/libreadline.so.6.3 7f71448ad000-7f71448b3000 rw-p 0003f000 08:07 1970756 /lib/x86_64-linux-gnu/libreadline.so.6.3 7f71448b3000-7f71448b4000 rw-p 00:00 0 7f71448b4000-7f71449bc000 r-xp 08:07 1966312 /lib/x86_64-linux-gnu/libm-2.23.so 7f71449bc000-7f7144bbb000 ---p 00108000 08:07 1966312 /lib/x86_64-linux-gnu/libm-2.23.so 7f7144bbb000-7f7144bbc000 r--p 00107000 08:07 1966312 /lib/x86_64-linux-gnu/libm-2.23.so 7f7144bbc000-7f7144bbd000 rw-p 00108000 08:07 1966312 /lib/x86_64-linux-gnu/libm-2.23.so 7f7144bbd000-7f7144bbf000 r-xp 08:07 1966307 /lib/x86_64-linux-gnu/libutil-2.23.so 7f7144bbf000-7f7144dbe000 ---p 2000 08:07 1966307 /lib/x86_64-linux-gnu/libutil-2.23.so 7f7144dbe000-7f7144dbf000 r--p 1000 08:07 19663
[issue43509] CFunctionType object should be hashable in Python
New submission from Xinmeng Xia : See the following examples, ctypes.resize is a built-in function and it's hashable. ctypes.memset is a C function (CFunctionType object) and it's “unhashable”. However, ctypes.resize and ctypes.memset are both immutable. They should act the same in Python. It should not report unhashable type error when ctypes.memset calls __hash__(). --- >>> import ctypes >>> ctypes.resize >>> ctypes.resize.__hash__() 146309 >>> ctypes.memset >>> ctypes.memset.__hash__() Traceback (most recent call last): File "", line 1, in TypeError: unhashable type --- Python version: 3.9.2 system: Ubuntu Expected output: ctypes.memset is hashable. -- components: Interpreter Core messages: 388804 nosy: xxm priority: normal severity: normal status: open title: CFunctionType object should be hashable in Python type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43508] Miscompilation information for tarfile.open() when given too many arguments
New submission from Xinmeng Xia : In following example, we only give 10 arguments to tarfile.open(). The error message shows "11 arguments were given".We give it 5 arguments and the error message shows "6 were given". This is not correct. == >>> tarfile.open(*[None]*10) Traceback (most recent call last): File "", line 1, in TypeError: open() takes from 1 to 5 positional arguments but 11 were given >>> tarfile.open(1,2,3,4,5) Traceback (most recent call last): File "", line 1, in TypeError: open() takes from 1 to 5 positional arguments but 6 were given == Expected Output: For 10 given arguments. the error message is "open() takes from 1 to 5 positional arguments but 10 were given" Python: 3.9.2 System: ubuntu 16.04 -- components: Library (Lib) messages: 388803 nosy: xxm priority: normal severity: normal status: open title: Miscompilation information for tarfile.open() when given too many arguments type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43508> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43507] Variables in locals scope fails to be printed.
New submission from Xinmeng Xia : The following code 1 calls function 'compile' and 'exec' and execute a statement "s=1". Then we print the value of 's'. This code can perform well on Python 3.9.2 and output the expected result. However, we pack the whole code into a function (code 2). The execution fails. code 1: === mstr = "s=1" exec(compile(mstr,'','exec')) print(s) === output: 1 code2: === def foo(): mstr = "s=1" exec(compile(mstr,'','exec')) print(s) foo() === output: Traceback (most recent call last): File "/home/xxm/Desktop/apifuzz/doc/genDoc.py", line 37, in foo() File "/home/xxm/Desktop/apifuzz/doc/genDoc.py", line 35, in foo print(s) NameError: name 's' is not defined By the way, we print locals(). 's' exists in the local scope. It should not fail. >>print(locals()) {'mstr': 's=1', 's': 1} -- components: Interpreter Core messages: 388802 nosy: xxm priority: normal severity: normal status: open title: Variables in locals scope fails to be printed. type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43507> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43471] Fails to import bz2 on Ubuntu
New submission from Xinmeng Xia : Module bz2 fails to be imported on Ubuntu due to lack of '_bz2'. We try "import bz2" on Mac, it can work well. Errors on Ubuntu == >>import bz2 Traceback (most recent call last): File "/home/xxm/Desktop/apifuzz/doc/genDoc.py", line 97, in exec(compile(mstr,'','exec')) File "", line 1, in File "/home/xxm/Desktop/apifuzz/Python-3.9.2/Lib/bz2.py", line 18, in from _bz2 import BZ2Compressor, BZ2Decompressor ModuleNotFoundError: No module named '_bz2' === Python version: 3.9.2 Python installation: (1). download source code from python.org, (2). run command "./configure; sudo make; sudo make install. We install the same Python 3.9.2 in a same way on Mac and Ubuntu. -- components: Library (Lib) messages: 388483 nosy: xxm priority: normal severity: normal status: open title: Fails to import bz2 on Ubuntu type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43470] Installation of Python 3.6.13 fails on MacOS Big Sur 11.2.3
New submission from Xinmeng Xia : Installation of latest Python 3.6.13 fails on MacOS Big Sur 11.2.3. The source code is downloaded from python.org. Then we try to install it by commands "./configure;sudo make;sudo make install". However the installation crashes. The installation succeeds on Ubuntu. Crash information: == >>./configure >>sudo make gcc -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall-std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Programs/python.o ./Programs/python.c . t -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -I. -I./Include-DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c:8210:15: error: implicit declaration of function 'sendfile' is invalid in C99 [-Werror,-Wimplicit-function-declaration] ret = sendfile(in, out, offset, &sbytes, &sf, flags); ^ ./Modules/posixmodule.c:10432:5: warning: code will never be executed [-Wunreachable-code] Py_FatalError("abort() called from Python code didn't abort!"); ^ 1 warning and 1 error generated. make: *** [Modules/posixmodule.o] Error 1 -- components: Installation messages: 388482 nosy: xxm priority: normal severity: normal status: open title: Installation of Python 3.6.13 fails on MacOS Big Sur 11.2.3 type: crash versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue43470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43469] Python 3.6 fails to run on MacOS (Big Sur 11.2.3)
New submission from Xinmeng Xia : Python 3.6 can work well on old version of MacOS. When I upgrade MacOS to the latest version Big Sur 11.2.3. Python 3.6 fails to start and crashes. Python 3.7, 3.8, 3.9 can perform well on the new version MacOS Big Sur 11.2.3. The crash information attached as follows: Crash information == >>python3.6 dyld: Library not loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation Referenced from: /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python Reason: image not found Abort trap: 6 == -- components: macOS messages: 388481 nosy: ned.deily, ronaldoussoren, xxm priority: normal severity: normal status: open title: Python 3.6 fails to run on MacOS (Big Sur 11.2.3) type: crash versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue43469> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43081] Recursive call crash module multiprocessing
New submission from Xinmeng Xia : The following code recursively calls function test_forkserver(). However, the output is not expected RecursionError(recursively calling) or OSError(too many open files). An unexpected EOFError ( inside module multiprocessing, not this code itself) is reported. According to the error message, Python interpreter seems to behavior abnormal on line 1, "import multiprocessing". I try other cases in my machine, multiprocessing module can work well. Only this case will crash module multiprocessing. test.py == import multiprocessing import os def do(i): print(test_forkserver(), os.getpid()) def test_forkserver(): mp = multiprocessing.get_context('forkserver') mp.Pool(2).map(do(mp), range(3)) if __name__ == '__main__': test_forkserver() == Attached output: -- Traceback (most recent call last): File "", line 1, in File "/usr/local/python3.10/lib/python3.10/multiprocessing/forkserver.py", line 258, in main fds = reduction.recvfds(s, MAXFDS_TO_SEND + 1) File "/usr/local/python3.10/lib/python3.10/multiprocessing/reduction.py", line 159, in recvfds raise EOFError EOFError ... -- System Info: >>uname -a Linux xxm 5.4.0-65-generic #73-Ubuntu SMP Mon Jan 18 17:25:17 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux >>python -V Python 3.10.0a4 -- components: Library (Lib) messages: 386008 nosy: xxm priority: normal severity: normal status: open title: Recursive call crash module multiprocessing type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42951] Random and infinite loop in dealing with recursion error for "try-except "
Xinmeng Xia added the comment: oh,I see. By the way, I set the argument of sys.setrecursionlimit to 10 in this program and a segmentation fault is reported. Is that normal? -- ___ Python tracker <https://bugs.python.org/issue42951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42888] Not installed “libgcc_s.so.1” causes exit crash.
Xinmeng Xia added the comment: I think the crash is fixed by this PR. I try other arguments. No crash is reported. Thank you! -- ___ Python tracker <https://bugs.python.org/issue42888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42888] Not installed “libgcc_s.so.1” causes exit crash.
Xinmeng Xia added the comment: No crash is reported anymore. The result is like following: - ... OSError: [Errno 24] Too many open files OSError: [Errno 24] Too many open files OSError: [Errno 24] Too many open files OSError: [Errno 24] Too many open files OSError: [Errno 24] Too many open files File "/home/xxm/Downloads/cpython-a4afb55fb226e1debcdaaf80890b790198ba14cc/Lib/socket.py", line 953, in getaddrinfo File "/home/xxm/Downloads/cpython-a4afb55fb226e1debcdaaf80890b790198ba14cc/Lib/socket.py", line 953, in getaddrinfo OSError: [Errno 24] Too many open files File "/home/xxm/Downloads/cpython-a4afb55fb226e1debcdaaf80890b790198ba14cc/Lib/socket.py", line 953, in getaddrinfo OSError: [Errno 24] Too many open files OSError: [Errno 24] Too many open files OSError: [Errno 24] Too many open files --- -- ___ Python tracker <https://bugs.python.org/issue42888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42717] The python interpreter crashed with "_enter_buffered_busy"
Xinmeng Xia added the comment: It seems that this bug won't be fixed. Should this issue be closed now? -- ___ Python tracker <https://bugs.python.org/issue42717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42951] Random and infinite loop in dealing with recursion error for "try-except "
New submission from Xinmeng Xia : In issue 42500, recursive calls in "Try-except" are resolved. This PR has fixed the crashes of some programs, such as program 1. And the core dump error is replaced with RecursiveError. However, program 2 will not report a RecursiveError. The program will fall into an infinite loop. Even "Ctrl C" cannot stop the infinite loop. I try to track the execution of this program and insert "print" information(see program 3). The output seems random in execution between try branch and except branch! I think this is a new bug after fixing 42500. I believe the program should also return RecursiveError. Program 1 === def foo(): try: 1/0 except: foo() foo() Program 2 def foo(): try: foo() except: foo() foo() Program 3 def foo(): try: print("a") foo() except: print("b") foo() foo() Output for program3( unexpected infinite random loop. ): ..bbbbabbaabbabbaaabbabbaabbabbbbabbaabbabbaaabbabbaabbabbbbabbaabbabbaaabbabbaabbabbabbabbaabbabbaaabbabbaabbabbbbabbaabbabbaaabbabbaabbabbaabbabbaabbabbaaabbabbaabbabbbb.. >>python -V Python 3.10.0a4 -- components: Interpreter Core messages: 385171 nosy: xxm priority: normal severity: normal status: open title: Random and infinite loop in dealing with recursion error for "try-except " type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42950] Incorrect exception behavior in handling recursive call.
New submission from Xinmeng Xia : Seeing the following programs, we try to catch a recursive call error in exception handling. The behaviors between Python 3.10.0a4 and older version are inconsistent. The outputs are attached in the end. The output on Python 3.10.0a4 is very weird. Two "print statements" lie in same "except" block to print "exception info" and a string "kk". "kk" is printed once while "exception info" is printed twice! I think a bug probably exists in Python 3.10.0a4 parser on handling stacks. = def foo(c): try: c = c + 1 print("ss"+str(c)) foo(c) except Exception as e: print(str(e)) print("kk") print(c) c = 0 foo(c) = Output in Python 3.10.0a2 and older version(expected) ss1 ss2 ss996 maximum recursion depth exceeded while calling a Python object kk 996 995 .. 3 2 1 Output in Python 3.10.0a4 (unexpected) ss1 ss2 ss996 maximum recursion depth exceeded while calling a Python object maximum recursion depth exceeded while calling a Python object kk 995 .. 3 2 1 -- components: Interpreter Core messages: 385170 nosy: xxm priority: normal severity: normal status: open title: Incorrect exception behavior in handling recursive call. type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42950> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42889] Incorrect behavior after ast node visits
Xinmeng Xia added the comment: Thank you for your kindly explanations! The output of the first program in msg384799 behaves as expected from the view of AST compiling. Yes,I see now. But for the second example in msg384879, the behaviors are inconsistent between old Python version(3.6,3.7,3.8) and new Python version(3.9,3.10). It is probably something wrong in "compile" parsing bool string, "False","True" in new version of Python(3.9,3.10). I think a checker in function "compile" will not be complicated. Like you said, the simplest way I can think is to re-perform lexical analysis and syntax analysis. e.g. unparse ast, then parse ast before compiling AST object. As for #42887, only part of attributes will lead to that bug. I think it's attribute-related. If that bug is triggered by c loop, all attributes should be involved. -- ___ Python tracker <https://bugs.python.org/issue42889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42887] 100000 assignments of .__sizeof__ cause a segfault on del
Xinmeng Xia added the comment: Thank you. But I am not sure this is a recursion problem. Please see the following example, I replace "__sizeof__" with "__class__". No segmentation fault. Everything goes well. mystr = "hello123" print(dir(mystr)) for x in range(100): mystr = mystr.__class__ print(mystr) = and = mystr = "hello123" for x in range(100): mystr = mystr.__class__ input('>') # Hit Enter to continue. del mystr # Expect crash here. input('<') # And never get here = No segmentation fault -- ___ Python tracker <https://bugs.python.org/issue42887> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42762] infinite loop resulted by "yield"
Xinmeng Xia added the comment: I see,Thank you! -- ___ Python tracker <https://bugs.python.org/issue42762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42918] Nested multi-line expression will lead to "compile()" fails
Xinmeng Xia added the comment: For sure! As soon as we validate this technique, we will open source it on GitHub. -- ___ Python tracker <https://bugs.python.org/issue42918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42918] Nested multi-line expression will lead to "compile()" fails
Xinmeng Xia added the comment: The bytecode of c is as following: 0 LOAD_CONST 0 (1) 2 STORE_NAME 0 (d) 4 LOAD_CONST 1 (None) 6 RETURN_VALUE === Yes, my team is working on developing a new fuzzier for the CPython. Also, we are trying to apply it on the newest version of CPython. We will carefully analyze all bugs before reporting them on the tracker. Hope our work does not bother you too much. -- ___ Python tracker <https://bugs.python.org/issue42918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42918] Nested multi-line expression will lead to "compile()" fails
Change by Xinmeng Xia : -- components: +Interpreter Core ___ Python tracker <https://bugs.python.org/issue42918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42919] Blank in multiline “if expressions” will lead to EOF errors
New submission from Xinmeng Xia : In build-in function compile() of mode 'single', single statement can be well compiled. (see program 1 and program 2). However, if we leave 4 blank spaces before the end of triple-quotation mark of "if expression",(see program 3), The parser will raise syntax error. This is not the expected output. Spaces in the end of multi-line expression should not affect the compilation results. No error should be reported in this case. program 1 (expected) === snippet =""" a = 1 """ compile(snippet, "", "single") === program 2 (expected) === snippet =""" if True: a = 1 """ compile(snippet, "", "single") === program 3 (unexpected) === snippet =""" if True: a = 1 """ compile(snippet, "", "single") === Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/report/test1.py", line 1, in compile(snippet, "", "single") File "", line 4 SyntaxError: unexpected EOF while parsing Expected output: No error reported (like program1 and program2) >> python -V Python 3.10.0a2 >>uname -a Linux xxm-System-Product-Name 4.15.0-64-generic #73~16.04.1-Ubuntu SMP Fri Sep 13 09:56:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux -- components: Interpreter Core messages: 384996 nosy: xxm priority: normal severity: normal status: open title: Blank in multiline “if expressions” will lead to EOF errors type: compile error versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42918] Nested multi-line expression will lead to "compile()" fails
New submission from Xinmeng Xia : For build-in function compile() in mode 'single', only single statement can be well compiled. If we compile multiple statements, the parser will raise a syntaxError. Seeing the following two programs, In program 1, 2 statement are compiled. So the parser raises a Syntax error. It's the expected output. However, if we insert a nested multi-line assignment in this code(see program 2), 3 statements are compiled. We expect the parser also raise a Sytax error. But it' not. Program 1 ( with expected results) === code1 = """ a = 1 b = 2 """ c = compile(code1, "", "single") === Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/report/test1.py", line 641, in c = compile(code1, "", "single") File "", line 2 a = 1 ^ SyntaxError: multiple statements found while compiling a single statement Program 2 (with unexpected results) = code2 = """ c =''' d=1 ''' a = 1 b = 2 """ c = compile(code2, "", "single") = Expected out for program 2: Raise a syntaxError too, But it's not. >> python -V Python 3.10.0a2 >>uname -a Linux xxm-System-Product-Name 4.15.0-64-generic #73~16.04.1-Ubuntu SMP Fri Sep 13 09:56:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux -- messages: 384995 nosy: xxm priority: normal severity: normal status: open title: Nested multi-line expression will lead to "compile()" fails type: compile error versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42889] Incorrect behavior of Python parser after ast node of test program being modified
Xinmeng Xia added the comment: Nice suggestion! I change the argument and I can' find segfault program in transforming ast.Name. But I do find a segfault program in transforming ast.BinOp! Seeing the following example, this program will cause a segmentation fault on Python 3.10. No error will be reported during tranforming of node, but Python crashes during compiling the modified AST. import ast class RewriteName(ast.NodeTransformer): def visit_BinOp(self, node): if node.left.value == 1: node.left = node return node code = """ mystr = 1 + (2+3) """ myast = ast.parse(code) transformer = RewriteName() newast = transformer.visit(myast) c = compile(newast,'','exec') exec(c) === I really think we should add a checker before compiling modified ast node or cancel the function of compiling AST object. An illegal AST of a program should not throw into "compile" function directly. -- type: behavior -> crash ___ Python tracker <https://bugs.python.org/issue42889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42889] Incorrect behavior of Python parser after ast node of test program being modified
Xinmeng Xia added the comment: Sorry, my description is a little confusing. My points lie on function 'compile' and 'exec'. Yes, I agree. AST can be modified and don't correspond to valid programs. But I don't think this invaild program can be compiled and exec without any check. It's dangerous. See the following program: For "compile" and "exec", no error is reported on Python 3.5-3.8 while error messages are reported on Python 3.9 and 3.10 == import ast class RewriteName(ast.NodeTransformer): def visit_Name(self, node): if node.id != "print": node.id = str(False) print(type(node.id)) return node code = "a = 2;print(a)" myast = ast.parse(code) transformer = RewriteName() newast = transformer.visit(myast) c = compile(newast,'','exec') exec(c) = Error message on Python 3.9 and 3.10. - Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/report/test1.py", line 574, in c = compile(newast,'','exec') ValueError: Name node can't be used with 'False' constant - In fact, in class RewriteName, when "node.id" is assigned, the parser will check whether the identifier is a "str". If not,"TypeError: AST identifier must be of type str" will be reported. However, it's not enough. In Python, identifier names have their own naming rules. "str" could be "+","1","False", but these are not legally id. So the above error could be reported. -- ___ Python tracker <https://bugs.python.org/issue42889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42888] Not installed “libgcc_s.so.1” causes parser crash.
Xinmeng Xia added the comment: >>uname -a Linux xxm-System-Product-Name 4.15.0-64-generic #73~16.04.1-Ubuntu SMP Fri Sep 13 09:56:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux >>uname -r 4.15.0-64-generic >>lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 16.04.3 LTS Release:16.04 Codename: xenial I download Python from https://www.python.org/downloads/. Then I extract it,run install command ./configure,make,sudo make install. I also try the versions of Python 3.5-3.10 and even cPython on GitHub. The results are the same. But when I try this program on Python 2, the program will not cause core dump. I think Python 2 is initially installed with the system, not by me. So I guess no link is referred to libgcc_s.so.1 when I install new version of Python. -- ___ Python tracker <https://bugs.python.org/issue42888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42888] Not installed “libgcc_s.so.1” causes parser crash.
Xinmeng Xia added the comment: >>python310 -V Python 3.10.0a2 >>uname -v #73~16.04.1-Ubuntu SMP Fri Sep 13 09:56:18 UTC 2019 Thank you! -- ___ Python tracker <https://bugs.python.org/issue42888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42889] Incorrect behavior of Python parser after ast node of test program being modified
New submission from Xinmeng Xia : The following program will lead to a incorrect behavior of Python parser. We change all variable to integer( forcely transformed to string) via ast.NodeTransformer. Then we compile the new code and execute it. It's surprising that code like "1=2; print(1)" can be compiled without error message. And more surprisingly, the execution result of "print(1)" is 2 ! ! import ast class RewriteName(ast.NodeTransformer): def visit_Name(self, node): if node.id != "print": node.id = str(node.lineno) return node code = "a = 2;print(a)" myast = ast.parse(code) transformer = RewriteName() newast = transformer.visit(myast) # print(ast.dump(newast)) print("new code:","") print(ast.unparse(newast)) print("") c = compile(newast,'','exec') exec(c) = output result: new code: 1 = 2 print(1) 2 Expected result: (1). Syntax error during compilation. "1" should not be the correct identifier of program, even if it's forcely transformed to string. (2). The output of execution should be "1" , since the parameter of "print()" in the new code is string "1". This incorrect behaviors exists on all version of Python(from Python2 to Python 3). -- components: Interpreter Core messages: 384799 nosy: xxm priority: normal severity: normal status: open title: Incorrect behavior of Python parser after ast node of test program being modified type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42888] Not installed “libgcc_s.so.1” causes parser crash.
New submission from Xinmeng Xia : The following thread program will cause Python3.10 parser "core dump" due to missing “libgcc_s.so.1”. "pthread_cancel" cannot work correctly. I am wondering is there any possible to install or link to libgcc_s.so.1 during Python installation? === import socket from threading import Thread class thread(Thread): def run(self): for res in socket.getaddrinfo('www.google.com',8080): sock = socket.socket() sock.connect(res[4]) for i in range(2000): thread().start() Error message: --- Exception in thread Thread-1346: Traceback (most recent call last): File "/usr/local/python310/lib/python3.10/threading.py", line 960, in _bootstrap_inner File "/usr/local/python310/lib/python3.10/threading.py", line 960, in _bootstrap_inner Exception in thread Thread-1172: Traceback (most recent call last): ... Exception in thread Thread-1509: Exception in thread Thread-1510: libgcc_s.so.1 must be installed for pthread_cancel to work Exception in thread Thread-1511: Traceback (most recent call last): Aborted (core dumped) --- -- components: Interpreter Core messages: 384798 nosy: xxm priority: normal severity: normal status: open title: Not installed “libgcc_s.so.1” causes parser crash. type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42887] Multiple assignments of attribute "__sizeof__" will cause a segfault
New submission from Xinmeng Xia : In the following program 1, method "__sizeof__()" is called and assigned multiple times. The program can work well on Python 3.10. However if I change "__sizeof__()" to "__sizeof__". Then a segmentation fault is reported. I think something wrong for the parser when dealing build-in attribute assignment. program 1: = mystr = "hello123" for x in range(100): mystr = mystr.__sizeof__() print(mystr) = 56 28 28 ... 28 28 Output: work well as expected. program 2: == mystr = "hello123" for x in range(100): mystr = mystr.__sizeof__ print(mystr) == .. Segmentation fault (core dumped) Expected output: no segfault. -- components: Interpreter Core messages: 384797 nosy: xxm priority: normal severity: normal status: open title: Multiple assignments of attribute "__sizeof__" will cause a segfault type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42887> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42762] infinite loop resulted by "yield"
Xinmeng Xia added the comment: I get a little confused. So is it a bug in Python 3.5 and 3.6? -- ___ Python tracker <https://bugs.python.org/issue42762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42858] Incorrect return value for os.system() in recognizing import error
Change by Xinmeng Xia : -- type: -> compile error ___ Python tracker <https://bugs.python.org/issue42858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42858] Incorrect return value for os.system() in recognizing import error
New submission from Xinmeng Xia : Running attached "test_zipfile.py" on Python 3.10 will lead to the following error messages: Exception ignored in: Traceback (most recent call last): File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 401, in temp_dir File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 358, in rmtree File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 322, in _rmtree ImportError: sys.meta_path is None, Python is likely shutting down Exception ignored in: Traceback (most recent call last): File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 401, in temp_dir File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 358, in rmtree File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 322, in _rmtree ImportError: sys.meta_path is None, Python is likely shutting down However, if we run this program with os.system, the return value is 0 instead of 256. 0 represent no fails in this running! This is obviously incorrect. Reproduce: = import os scode = os.system('python310 test_zipfile.py') print("The system code of this execution is:", scode) = The expected output: "The system code of this execution is: 256" The actual output: "The system code of this execution is: 0" Version info: >>python310 -V Python 3.10.0a2 >>uname -v 16.04.1-Ubuntu SMP Fri Sep 13 09:56:18 UTC 2019 -- components: Library (Lib) files: test_zipfile.py messages: 384582 nosy: xxm priority: normal severity: normal status: open title: Incorrect return value for os.system() in recognizing import error versions: Python 3.10 Added file: https://bugs.python.org/file49726/test_zipfile.py ___ Python tracker <https://bugs.python.org/issue42858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42857] Fails to construct paths lead to "python is likely shutting down"
New submission from Xinmeng Xia : The attached file "test_zipfile.py" is from test directory in cPython. We delete irrelevant code. Running this code on Python 3.10 will lead to the following error messages. Exception ignored in: Traceback (most recent call last): File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 401, in temp_dir File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 358, in rmtree File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 322, in _rmtree ImportError: sys.meta_path is None, Python is likely shutting down Exception ignored in: Traceback (most recent call last): File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 401, in temp_dir File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 358, in rmtree File "/usr/local/python310/lib/python3.10/test/support/os_helper.py", line 322, in _rmtree ImportError: sys.meta_path is None, Python is likely shutting down The expected output should be something like" ImportError: No module named XXX" rather than "Python is likely shutting down" -- components: Interpreter Core files: test_zipfile.py messages: 384581 nosy: xxm priority: normal severity: normal status: open title: Fails to construct paths lead to "python is likely shutting down" type: crash versions: Python 3.10 Added file: https://bugs.python.org/file49725/test_zipfile.py ___ Python tracker <https://bugs.python.org/issue42857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42852] pprint fails in transformming non-breaking space
New submission from Xinmeng Xia : "pprint" can transform unicode like "print". However, pprint fails to transform non-breaking space('\240') . See the following example: Python 3.10.0a2 (default, Nov 24 2020, 14:18:46) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. Example 1(Results as expected): - >>> import pprint >>> print(u'\041 hello') ! hello >>> pprint.pprint(u'\041 hello') '! hello' Example 2(Results not as expected): - >>> print(u'\240 hello') hello >>> pprint.pprint(u'\240 hello') '\xa0 hello' Expected output: the output of pprint.pprint(u'\240 hello') should be consistent with output of print(u'\240 hello') -- components: Unicode messages: 384564 nosy: ezio.melotti, vstinner, xxm priority: normal severity: normal status: open title: pprint fails in transformming non-breaking space type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42813] Extra spaces cause unexpected EOF error in "compile" function with mode "single"
New submission from Xinmeng Xia : Running the following program will lead to an unexpected EOF error. If we delete the space before triple-quotation mark("""), the error will gone. If we replace the content of snippet with "a = 1", the program will work well. However, if we replace the content of snippet with "if a:pass" in a single line, the program cause an error again. This is weird. Spaces in the end of a statement should not affect the compilation of program in "single" mode. Besides, the error messages are different in Python2 and Python3. Indentation error are reported in Python 2 for snippet" if a:pass" while SyntaxError are reported in Python 3. == import math def check_stack_size( code): # To assert that the alleged stack size is not O(N), we # check that it is smaller than log(N). if isinstance(code, str): code = compile(code, "", "single") max_size = math.ceil(math.log(len(code.co_code))) # self.assertLessEqual(code.co_stacksize, max_size) def test_if_else(): snippet =""" if x: a elif y: b else: c """ check_stack_size(snippet) test_if_else() = Behavior in Python 3.10: Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/report/temp.py", line 30, in test_if_else() File "/home/xxm/Desktop/nameChanging/report/temp.py", line 20, in test_if_else check_stack_size(snippet) File "/home/xxm/Desktop/nameChanging/report/temp.py", line 6, in check_stack_size code = compile(code, "", "single") File "", line 8 SyntaxError: unexpected EOF while parsing Behaviors in Python2: Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/report/temp.py", line 30, in test_if_else() File "/home/xxm/Desktop/nameChanging/report/temp.py", line 27, in test_if_else check_stack_size(snippet) File "/home/xxm/Desktop/nameChanging/report/temp.py", line 6, in check_stack_size code = compile(code, "", "single") File "", line 3 ^ IndentationError: unexpected indent -- components: Interpreter Core messages: 384257 nosy: xxm priority: normal severity: normal status: open title: Extra spaces cause unexpected EOF error in "compile" function with mode "single" type: compile error versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42763] Exposing a race in the "_warnings" resulting Python parser crash
Xinmeng Xia added the comment: Now I see. By the way, I think this case should be moved back to "cpython/Lib/test/crashers/" since the bug still exists. It is not fixed completely, the old case is outdated. I suggest we can put the new case into directory "crashers". -- ___ Python tracker <https://bugs.python.org/issue42763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42717] The python interpreter crashed with "_enter_buffered_busy"
Xinmeng Xia added the comment: Thank you for your patient reply. I see now. Hoping that some one can figure out a good idea to fix this problem. -- ___ Python tracker <https://bugs.python.org/issue42717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42717] The python interpreter crashed with "_enter_buffered_busy"
Xinmeng Xia added the comment: Could we try to limit the number of thread or state or something? I mean if we set parameter of "range", for example, to 1000 or less here, the crash will no longer happen. I think the parser can not handle too heavy loop so that it crashes. -- ___ Python tracker <https://bugs.python.org/issue42717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42763] Exposing a race in the "_warnings" resulting Python parser crash
Xinmeng Xia added the comment: Thank you, but I don't think this is a duplicate of issue42717. This crash is probably caused by the parameter "target" of Thread. "Target" accept the "callable object". Defaults to None. In this program, it's assigned to a "Int object". I think a pre-checking of parameter for such error should be added. Minimal test case should be: === import threading for i in range(10): t = threading.Thread(target=1, daemon=True).start() = In fact, I try this one. No loop, It sometime crashes the parser.(not always, twice in ten times) == import threading t = threading.Thread(target=1, daemon=True).start() == -- ___ Python tracker <https://bugs.python.org/issue42763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42762] infinite loop resulted by "yield"
Xinmeng Xia added the comment: Thanks for your kind explanation! My description is a little confusing. Sorry about that. The problem here is that the program should stop when the exception is caught whatever the exception is. (I think bpo-25612 (#1773) fixed exception selection problems and right exception can be caught) The fact is this program will fall into an infinite loop. Error messages are printed in a dead loop. The program doesn't stop. This is not normal. There will be no loops in Python 3.5 and 3.6 (Attached output in Python 3.5 and 3.6). Output on Python 3.5,3.6 (all errors are printed without any loop ) - Exception ignored in: RuntimeError: generator ignored GeneratorExit Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/report/test1.py", line 248, in print(i) NameError: name 'i' is not defined Exception ignored in: RuntimeError: generator ignored GeneratorExit Exception ignored in: RuntimeError: generator ignored GeneratorExit -- ___ Python tracker <https://bugs.python.org/issue42762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42763] Exposing a race in the "_warnings" resulting Python parser crash
New submission from Xinmeng Xia : This program is initially from "cpython/Lib/test/crashers/warnings_del_crasher.py" in Python 2.7. The original case is fixed for all version of Python and removed from "crashers" directory. However, if we replace the statement "for i in range(10):" of original program with the statement "for do_work in range(10):" . The race will happen again, and it will crash Python 3.7 - 3.10. == import threading import warnings class WarnOnDel(object): def __del__(self): warnings.warn("oh no something went wrong", UserWarning) def do_work(): while True: w = WarnOnDel() -for i in range(10): +for do_work in range(10): t = threading.Thread(target=do_work) t.setDaemon(1) t.start() = Error messages on Python 3.7-3.10: --- Exception in thread Thread-2: Traceback (most recent call last): File "/usr/local/python310/lib/python3.10/threading.py", line 960, in _bootstrap_inner Exception in thread Thread-3: Traceback (most recent call last): Exception in thread Thread-4: File "/usr/local/python310/lib/python3.10/threading.py", line 960, in _bootstrap_inner Exception in thread Thread-5: Traceback (most recent call last): self.run() Traceback (most recent call last): self.run() Exception in thread Thread-6: Exception in thread Thread-8: Exception in thread Thread-9: Exception in thread Thread-10: Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name=''> at interpreter shutdown, possibly due to daemon threads Python runtime state: finalizing (tstate=0x2679180) Current thread 0x7f3481d3a700 (most recent call first): Aborted (core dumped) -- components: Interpreter Core messages: 383883 nosy: xxm priority: normal severity: normal status: open title: Exposing a race in the "_warnings" resulting Python parser crash type: crash versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42762] infinite loop resulted by "yield"
New submission from Xinmeng Xia : Let's see the following program: def foo(): try: yield except: yield from foo() for m in foo(): print(i) === Expected output: On line"print(i)", NameError: name 'i' is not defined However, the program will fall into infinite loops when running it on Python 3.7-3.10 with the error messages like the following.(no infinite loop on Python 3.5 and Python 3.6) -- Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/report/test1.py", line 160, in print(i) RuntimeError: generator ignored GeneratorExit Exception ignored in: Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/report/test1.py", line 160, in print(i) RuntimeError: generator ignored GeneratorExit Exception ignored in: Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/report/test1.py", line 160, in print(i) RuntimeError: generator ignored GeneratorExit Exception ignored in: Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/report/test1.py", line 160, in print(i) .. -- -- components: Interpreter Core messages: 383882 nosy: xxm priority: normal severity: normal status: open title: infinite loop resulted by "yield" type: crash versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42734] Outdated CodeType call in "bogus_code_obj.py"
Xinmeng Xia added the comment: Yes,you are right. I thought it was fixed,but it wasn't. Thanks. -- type: enhancement -> behavior ___ Python tracker <https://bugs.python.org/issue42734> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42735] "trace_at_recursion_limit.py" should be removed from "Python/Lib/test/crashers"
Change by Xinmeng Xia : -- type: enhancement -> behavior ___ Python tracker <https://bugs.python.org/issue42735> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42735] "trace_at_recursion_limit.py" should be removed from "Python/Lib/test/crashers"
New submission from Xinmeng Xia : In "Python/Lib/test/crashers/", only tests for outstanding bugs that cause the interpreter to segfault should be included. The file "trace_at_recursion_limit.py" has been fixed on Python 3.7, 3.8, 3.9, 3.10. No segmentation fault will be caused any more. I think this file should be removed from "Python/Lib/test/crashers". -- components: Library (Lib) messages: 383722 nosy: xxm priority: normal severity: normal status: open title: "trace_at_recursion_limit.py" should be removed from "Python/Lib/test/crashers" type: enhancement versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42735> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42734] "bogus_code_obj.py" should be removed from "cPython/Lib/test/crashers"
New submission from Xinmeng Xia : In "Python/Lib/test/crashers/README", it said "This directory only contains tests for outstanding bugs that cause the interpreter to segfault. Once the crash is fixed, the test case should be moved into an appropriate test." The file "bogus_code_obj.py" has been fixed on Python 3.8, 3.9, 3.10. No segmentation fault will be caused any more. I think this file should be removed from "Python/Lib/test/crashers". -- components: Library (Lib) messages: 383721 nosy: xxm priority: normal severity: normal status: open title: "bogus_code_obj.py" should be removed from "cPython/Lib/test/crashers" type: enhancement versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42734> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42717] The python interpreter crashed with "_enter_buffered_busy"
Xinmeng Xia added the comment: Thanks for your kind explanation! Now, I have understand the causes of this core dump. Considering it will not cause core dump in Python 2.x, I am wondering should we suggest an exception to catch it rather than "core dump"? -- ___ Python tracker <https://bugs.python.org/issue42717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42717] The python interpreter crashed with "_enter_buffered_busy"
New submission from Xinmeng Xia : The following program can work well in Python 2. However it crashes in Python 3( 3.6-3.10 ) with the following error messages. Program: import sys,time, threading class test: def test(self): pass class test1: def run(self): for i in range(0,1000): connection = test() sys.stderr.write(' =_= ') def testrun(): client = test1() thread = threading.Thread(target=client.run, args=()) thread.setDaemon(True) thread.start() time.sleep(0.1) testrun() Error message: -- =_= =_= =_= =_= =_= .. =_= =_= =_= =_= Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name=''> at interpreter shutdown, possibly due to daemon threads Python runtime state: finalizing (tstate=0xd0c180) Current thread 0x7f08a638f700 (most recent call first): Aborted (core dumped) -- When I remove "time.sleep(0.1)" or "thread.setDaemon(True)" or "sys.stderr.write(' =_= ')" or "for i in range(0,1000)":, the python interpreter seems to work well. -- components: Interpreter Core messages: 383582 nosy: xxm priority: normal severity: normal status: open title: The python interpreter crashed with "_enter_buffered_busy" type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42716] Segmentation fault in running ast.parse() with large expression size.
New submission from Xinmeng Xia : Calling function ast.parse() with large size can cause a segmentation fault in Python 3.5 -3.10. Please check the following two examples. The example 1 works as expected, while the second one triggers segmentation fault on Python 3.5,3.6,3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the value of "n". Example 1: = import ast mylist = [] n = 10 print(ast.parse("mylist"+"+mylist"*n)) == The actual output: AST nodes on Python 3.5-3.10 (as expected) # <_ast.Module object at 0x7f78d7b672e8> Example 2: === import ast mylist = [] n = 100 print(ast.parse("mylist"+"+mylist"*n)) # <_ast.Module object at 0x7f78d7b672e8> === The actual output: segmentation fault on Python 3.5 - 3.10 (not as expected) My system information: >> python3.10 -V Python 3.10.0a2 >> python3.9 -V Python 3.9.0rc1 >> python3.8 -V Python 3.8.0 >> python3.7 -V Python 3.7.3 >> python3.6 -V Python 3.6.12 >> uname -v #73~16.04.1-Ubuntu -- components: Interpreter Core messages: 383581 nosy: xxm priority: normal severity: normal status: open title: Segmentation fault in running ast.parse() with large expression size. type: crash versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42715] Segmentation fault in running exec() with large expression size.
New submission from Xinmeng Xia : Calling function exec() with large size can cause a segmentation fault in Python 3.7 -3.10. Please check the following two examples. The example 1 works as expected, while the second one triggers segmentation fault on Python 3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the value of "n". Example 1: = mylist = [] n = 10 print(exec("mylist"+"+mylist"*n)) == The actual output: Recursion Error on Python 3.5-3.10 (as expected) Example 2: === mylist = [] n = 100 print(exec("mylist"+"+mylist"*n)) === The actual output: Recursive Error on Python 3.5, 3.6 (as expected), segmentation fault on Python 3.7, 3.8, 3.9, 3.10 (not as expected) My system information: >> python3.10 -V Python 3.10.0a2 >> python3.9 -V Python 3.9.0rc1 >> python3.8 -V Python 3.8.0 >> python3.7 -V Python 3.7.3 >> python3.6 -V Python 3.6.12 >> uname -v #73~16.04.1-Ubuntu -- components: Interpreter Core messages: 383580 nosy: xxm priority: normal severity: normal status: open title: Segmentation fault in running exec() with large expression size. type: crash versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42715> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42714] Segmentation fault in running compile() with large expression size.
New submission from Xinmeng Xia : Calling function compile() with large size can cause a segmentation fault in Python 3.7 -3.10. Please check the following two examples. The example 1 works as expected, while the second one triggers segmentation fault on Python 3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the value of "n". Example 1: = mylist = [] n = 10 print(compile("mylist"+"+mylist"*n,'','single')) == The actual output: Recursion Error on Python 3.5-3.10 (as expected) Example 2: = mylist = [] n = 100 print(compile("mylist"+"+mylist"*n,'','single')) === The actual output: Recursive Error on Python 3.5, 3.6 (as expected), segmentation fault on Python 3.7, 3.8, 3.9, 3.10 (not as expected) My system information: >> python3.10 -V Python 3.10.0a2 >> python3.9 -V Python 3.9.0rc1 >> python3.8 -V Python 3.8.0 >> python3.7 -V Python 3.7.3 >> python3.6 -V Python 3.6.12 >> uname -v #73~16.04.1-Ubuntu -- components: Interpreter Core messages: 383579 nosy: xxm priority: normal severity: normal status: open title: Segmentation fault in running compile() with large expression size. type: crash versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42714> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42713] Segmentation fault in running eval() with large expression size.
New submission from Xinmeng Xia : Calling function eval() with large size can cause a segmentation fault in Python 3.7 -3.10. Please check the following two examples. The example 1 works as expected, while the second one triggers segmentation fault on Python 3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the value of "n". Example 1: = mylist = [] n = 10 print(eval("mylist"+"+mylist"*n)) == The actual output: Recursion Error on Python 3.5-3.10 (as expected) Example 2: === mylist = [] n = 100 print(eval("mylist"+"+mylist"*n)) === The actual output: Recursive Error on Python 3.5, 3.6 (as expected), segmentation fault on Python 3.7, 3.8, 3.9, 3.10 (not as expected) My system information: >> python3.10 -V Python 3.10.0a2 >> python3.9 -V Python 3.9.0rc1 >> python3.8 -V Python 3.8.0 >> python3.7 -V Python 3.7.3 >> python3.6 -V Python 3.6.12 >> uname -v #73~16.04.1-Ubuntu -- components: Interpreter Core messages: 383578 nosy: xxm priority: normal severity: normal status: open title: Segmentation fault in running eval() with large expression size. type: crash versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42712] Segmentation fault in running ast.literal_eval() with large expression size.
New submission from Xinmeng Xia : Calling function ast.literal_eval() with large size can cause a segmentation fault in Python 3.5 -3.10. Please check the following two examples. The example 1 works as expected, while the second one triggers segmentation fault on Python 3.5,3.6,3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the value of "n". Example 1: = import ast mylist = [] n = 10 print(ast.literal_eval("mylist"+"+mylist"*n)) == The actual output: value Error on Python 3.5,3.7,3.8,3.9,3.10, Recursive Error on Python 3.6 (as expected) Example 2: === import ast mylist = [] n = 100 print(ast.literal_eval("mylist"+"+mylist"*n)) === The actual output: segmentation fault on Python 3.5 - 3.10 (not as expected) My system information: >> python3.10 -V Python 3.10.0a2 >> python3.9 -V Python 3.9.0rc1 >> python3.8 -V Python 3.8.0 >> python3.7 -V Python 3.7.3 >> python3.6 -V Python 3.6.12 >> uname -v #73~16.04.1-Ubuntu -- components: Interpreter Core messages: 383577 nosy: xxm priority: normal severity: normal status: open title: Segmentation fault in running ast.literal_eval() with large expression size. type: crash versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42712> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42651] Recursive traceback crashes Python Interpreter
Xinmeng Xia added the comment: Thank you very much, looking forward to the new Python version. Could you please kindly change the resolution into fixed and close this issue? -- ___ Python tracker <https://bugs.python.org/issue42651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42652] recursive in finally clause cause Python interpreter crash.
Xinmeng Xia added the comment: Thanks for fixing this, looking forward to the new version. Could you please kindly change the resolution into fixed and close this report? -- ___ Python tracker <https://bugs.python.org/issue42652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42651] Recursive traceback crashes Python Interpreter
Xinmeng Xia added the comment: In issue#36272, they discuss a bug in logging module. They show an example which is similar as this one. So I think I think there might be a similar bug in traceback module. -- ___ Python tracker <https://bugs.python.org/issue42651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42652] recursive in finally clause cause Python interpreter crash.
Xinmeng Xia added the comment: In issue #42500, crashes is resulted by recursion and try-except. Program like following will crash the interpreter. = def foo(): try: 1/0 except: pass foo() foo() = However with traceback module, program will no longer crash the interpreter. A recursive Error is returned as expected. = import traceback def foo(): try: 1/0 except: traceback.print_exc() foo() foo() = But it is still crash the interpreter in finally clause. I think this might be a new but and it is different from #42500. It should be related to traceback module, finally clause and recursion. what do you think? -- ___ Python tracker <https://bugs.python.org/issue42652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42651] Recursive traceback crashes Python Interpreter
Change by Xinmeng Xia : -- title: Title: Recursive traceback crashes Python Interpreter -> Recursive traceback crashes Python Interpreter ___ Python tracker <https://bugs.python.org/issue42651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42652] recursive in finally clause cause Python interpreter crash.
New submission from Xinmeng Xia : Considering the following two program,running the program 1 will get expected output: RecursionError program 1 === import traceback def foo(): try: 1/0 except Exception as e: traceback.print_exc() finally: a = 1 foo() foo() == --- ZeroDivisionError: division by zero Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo 1/0 ZeroDivisionError: division by zero Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo 1/0 ZeroDivisionError: division by zero During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo 1/0 ZeroDivisionError: division by zero Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo 1/0 ZeroDivisionError: division by zero During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 12, in File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10, in foo foo() File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10, in foo ... foo() File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10, in foo foo() File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 7, in foo traceback.print_exc() File "/usr/lib/python3.5/traceback.py", line 159, in print_exc print_exception(*sys.exc_info(), limit=limit, file=file, chain=chain) File "/usr/lib/python3.5/traceback.py", line 100, in print_exception type(value), value, tb, limit=limit).format(chain=chain): File "/usr/lib/python3.5/traceback.py", line 474, in __init__ capture_locals=capture_locals) File "/usr/lib/python3.5/traceback.py", line 358, in extract f.line File "/usr/lib/python3.5/traceback.py", line 282, in line self._line = linecache.getline(self.filename, self.lineno).strip() File "/usr/lib/python3.5/linecache.py", line 16, in getline lines = getlines(filename, module_globals) File "/usr/lib/python3.5/linecache.py", line 43, in getlines if len(entry) != 1: RecursionError: maximum recursion depth exceeded in comparison However when moving foo() into finally clause, the interpreter crashes. program 2 == import traceback def foo(): try: 1/0 except Exception as e: traceback.print_exc() finally: a = 1 foo() foo() == - File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10 in foo Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo 1/0 ZeroDivisionError: division by zero Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo 1/0 ZeroDivisionError: division by zero Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo 1/0 ZeroDivisionError: division by zero Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo 1/0 ZeroDivisionError: division by zero Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo 1/0 ZeroDivisionError: division by zero During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 7, in foo traceback.print_exc() File "/usr/lib/python3.5/traceback.py", line 159, in print_exc print_exception(*sys.exc_info(), limit=limit, file=file, chain=chain) File "/usr/lib/python3.5/traceback.py", line 100, in print_exception type(value), value, tb, limit=limit).format(chain=chain): File "/usr/lib/python3.5/traceback.py", line 474, in __init__ capture_locals=capture_locals) File "/usr/lib/python3.5/traceback.py", line 358, in extract f.line File "/usr/lib/python3.5/traceback.py", line 282, in line self._line = linecache.getline(self.filename, self.li
[issue42651] Title: Recursive traceback crashes Python Interpreter
New submission from Xinmeng Xia : = import traceback def foo(): traceback.print_exc() foo() foo() Try running the above program, the interpreter is crashed with the error message like the following: Fatal Python error: Cannot recover from stack overflow. NoneType: None NoneType: None NoneType: None NoneType: None ... NoneType: None NoneType: None NoneType: NoneType: None NoneType: None ... NoneType: None NoneType: None NoneType: None Fatal Python error: _Py_CheckRecursiveCall: Cannot recover from stack overflow. Python runtime state: initialized Current thread 0x7fab0bdda700 (most recent call first): File "/usr/local/python310/lib/python3.10/traceback.py", line 155 in _some_str File "/usr/local/python310/lib/python3.10/traceback.py", line 515 in __init__ File "/usr/local/python310/lib/python3.10/traceback.py", line 103 in print_exception File "/usr/local/python310/lib/python3.10/traceback.py", line 163 in print_exc File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 4 in foo File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo ... File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo ... Aborted (core dumped) -- components: Interpreter Core messages: 383118 nosy: xxm priority: normal severity: normal status: open title: Title: Recursive traceback crashes Python Interpreter type: crash versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42632] Reassgining ZeroDivisionError will lead to bug in Except clause
Xinmeng Xia added the comment: Similar bugs exist in other exceptions. -- ___ Python tracker <https://bugs.python.org/issue42632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42632] Reassgining ZeroDivisionError will lead to bug in Except clause
New submission from Xinmeng Xia : Running the following program: == def foo(): try: 1/0 except ZeroDivisionError as e: ZeroDivisionError = 1 foo() == The expected output should be nothing. ZeroDivisionError is caught and then reassignment is executed. However, running this program in Python3.10 will lead to the following error: Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/error/1.py", line 5, in foo 1/0 ZeroDivisionError: division by zero During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/error/1.py", line 8, in foo() File "/home/xxm/Desktop/nameChanging/error/1.py", line 6, in foo except Exception as e: UnboundLocalError: local variable 'Exception' referenced before assignment -- components: Interpreter Core messages: 382953 nosy: xxm priority: normal severity: normal status: open title: Reassgining ZeroDivisionError will lead to bug in Except clause type: compile error versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42509] Recursive calls crash interpreter when checking exceptions
Xinmeng Xia added the comment: But program like following program 3 will not cause any core dump, RecursionError is also being caught in this Recursion. program 3 def rec(): try: rec() except: pass rec() Beside,I use sys.setrecursionlimit(80), and the program 1 still cause core dump.I print sys.getrecursionlimit(),the value is 1000. 80 is << 50 +1000, it shouldn't cause core dump. -- ___ Python tracker <https://bugs.python.org/issue42509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42509] Recursive calls crash interpreter when checking exceptions
New submission from Xinmeng Xia : The following program 1 can crash in Python 3. We have reproduce it in the Python version 3.5, 3.6, 3.7, 3.8, 3.9, 3.10. This bug seems to be similar to issue 36272, however, the tracking system shows issue 36272 has been fixed and the program 2, which triggers issue 36272, will not cause crash (“core dump”) in Python 3.8, 3.9, 3.10. We have attached the stack trace in the end of this report. Program 1: import logging def rec(): try: logging.error("foo") except: pass rec() rec() Program 2: import logging def rec(): logging.error("foo") rec() rec() == The error message is like following: “ ERROR:root:foo ERROR:root:foo ERROR:root:foo ERROR:root:foo … ERROR:root:foo ERROR:root:foo ERROR:root:foo Fatal Python error: _Py_CheckRecursiveCall: Cannot recover from stack overflow. Python runtime state: initialized Current thread 0x7f0fa440b700 (most recent call first): File "/usr/local/python310/lib/python3.10/logging/__init__.py", line 420 in usesTime File "/usr/local/python310/lib/python3.10/logging/__init__.py", line 643 in usesTime File "/usr/local/python310/lib/python3.10/logging/__init__.py", line 675 in format File "/usr/local/python310/lib/python3.10/logging/__init__.py", line 938 in format File "/usr/local/python310/lib/python3.10/logging/__init__.py", line 1094 in emit File "/usr/local/python310/lib/python3.10/logging/__init__.py", line 963 in handle File "/usr/local/python310/lib/python3.10/logging/__init__.py", line 1673 in callHandlers File "/usr/local/python310/lib/python3.10/logging/__init__.py", line 1611 in handle File "/usr/local/python310/lib/python3.10/logging/__init__.py", line 1601 in _log File "/usr/local/python310/lib/python3.10/logging/__init__.py", line 1483 in error File "/usr/local/python310/lib/python3.10/logging/__init__.py", line 2080 in error File "/home/xxm/Desktop/methodfuzzer/error/loggingtest.py", line 8 in rec File "/home/xxm/Desktop/methodfuzzer/error/loggingtest.py", line 12 in rec File "/home/xxm/Desktop/methodfuzzer/error/loggingtest.py", line 12 in rec File "/home/xxm/Desktop/methodfuzzer/error/loggingtest.py", line 12 in rec …. File "/home/xxm/Desktop/methodfuzzer/error/loggingtest.py", line 12 in rec File "/home/xxm/Desktop/methodfuzzer/error/loggingtest.py", line 12 in rec File "/home/xxm/Desktop/methodfuzzer/error/loggingtest.py", line 12 in rec File "/home/xxm/Desktop/methodfuzzer/error/loggingtest.py", line 12 in rec File "/home/xxm/Desktop/methodfuzzer/error/loggingtest.py", line 12 in rec ... Aborted (core dumped)” -- components: Interpreter Core messages: 382111 nosy: xxm priority: normal severity: normal status: open title: Recursive calls crash interpreter when checking exceptions type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42500] status() crashes on Python3.9 and 3.10
New submission from Xinmeng Xia : This program can work well on Python 3.5.2 and Python2.7 with the following output. "Invalid Entry, try again" However it will crash on Python3.9.0rc1, 3.10.0a2 with the following error message: " Fatal Python error: _Py_CheckRecursiveCall: Cannot recover from stack overflow. Python runtime state: initialized Current thread 0x7fc4b679b700 (most recent call first): File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 38 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status File "/home/xxm/Desktop/methodfuzzer/error/error1.py", line 39 in status ... Aborted (core dumped) " -- components: Interpreter Core files: error1.py messages: 382042 nosy: xxm priority: normal severity: normal status: open title: status() crashes on Python3.9 and 3.10 type: crash versions: Python 3.9 Added file: https://bugs.python.org/file49635/error1.py ___ Python tracker <https://bugs.python.org/issue42500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42290] Unicode inconsistent display after concencated
New submission from Xinmeng Xia : When printing an assignment expression with unicode ܯ ( \U+072F) on the command line, we get an unexpected result. Example A: >>> print(chr(1839)+" = 1") ܯ = 1 Similar problems exist in plenty of characters of unicode. -- components: Unicode messages: 380534 nosy: ezio.melotti, vstinner, xxm priority: normal severity: normal status: open title: Unicode inconsistent display after concencated type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue42290> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42284] The grammar specification is inconsistent with the implementation of Python parser.
New submission from Xinmeng Xia : In full grammar specification of Python 3.6 official documentation (Python 3.6 official documentation: https://docs.python.org/3.6/reference/grammar.html ), we can find a very clear definition on the grammar about the usage of 'break'. According to the definition, we can find the following derivation, which indicates the keyword 'break' can appear in the block of if statement without being nested into a loop block: %% # Start symbols for the grammar: # single_input is a single interactive statement; single_input: NEWLINE | simple_stmt | compound_stmt NEWLINE compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | with_stmt | funcdef | classdef | decorated | async_stmt if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] suite: simple_stmt | NEWLINE INDENT stmt+ DEDENT simple_stmt: small_stmt (';' small_stmt)* [';'] NEWLINE small_stmt: (expr_stmt | del_stmt | pass_stmt | flow_stmt | import_stmt | global_stmt | nonlocal_stmt | assert_stmt) flow_stmt: break_stmt | continue_stmt | return_stmt | raise_stmt | yield_stmt break_stmt: 'break' %%% However, the implementation of the Python parser requires the 'break' can only be embedded into a loop statement. See the following example: Example A(without loop): >>> compile("if True:break",'','exec') Traceback (most recent call last): File "", line 1, in File "", line 1 SyntaxError: 'break' outside loop Example B(with a loop): >>> compile("while True:\n\tif True:break",'','exec') at 0x7f5f4de90b70, file "", line 1> Similar problems exist between if-statement and keywords: 'continue', 'yield', 'return', 'nonlocal' in Python 3.6 and later versions. -- assignee: docs@python components: Documentation messages: 380502 nosy: docs@python, xxm priority: normal severity: normal status: open title: The grammar specification is inconsistent with the implementation of Python parser. type: compile error versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue42284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37753] 2to3 not handing "<="
New submission from Xinmeng Xia : After conversion of 2to3 , run simple-example.py and the following error will happen. Traceback (most recent call last): File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/simple_example.py", line 15, in plays = nflgame.combine_plays(games) File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/nflgame/__init__.py", line 396, in combine_plays chain = itertools.chain(*[g.drives.plays() for g in games]) File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/nflgame/__init__.py", line 396, in chain = itertools.chain(*[g.drives.plays() for g in games]) File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/nflgame/game.py", line 407, in __getattr__ self.__drives = _json_drives(self, self.home, self.data['drives']) File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/nflgame/game.py", line 675, in _json_drives d = Drive(game, i, home_team, data[str(drive_num)]) File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/nflgame/game.py", line 516, in __init__ if self.time_end <= self.time_start \ TypeError: '<=' not supported between instances of 'GameClock' and 'GameClock' -- components: 2to3 (2.x to 3.x conversion tool) files: simple_example.py messages: 348961 nosy: xxm priority: normal severity: normal status: open title: 2to3 not handing "<=" type: compile error versions: Python 3.7 Added file: https://bugs.python.org/file48528/simple_example.py ___ Python tracker <https://bugs.python.org/issue37753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37718] 2to3 exception handling
New submission from Xinmeng Xia : we run the converted Python3 code, the following error will happen: Traceback (most recent call last): File "/home/xxm/Desktop/instrument/datasetpy3/Labeled-LDA-Python/example.py", line 50, in llda_model.save_model_to_dir(save_model_dir) File "/home/xxm/Desktop/instrument/datasetpy3/Labeled-LDA-Python/model/labeled_lda.py", line 697, in save_model_to_dir LldaModel._write_object_to_file(save_model_path, save_model.__dict__) File "/home/xxm/Desktop/instrument/datasetpy3/Labeled-LDA-Python/model/labeled_lda.py", line 650, in _write_object_to_file print(("%s\n\t%s" % (message, e.message))) AttributeError: 'TypeError' object has no attribute 'message' it seems that attributes change between Python2 and Python3. However 2to3 lack for this fix when dealing with exception fix. -- components: 2to3 (2.x to 3.x conversion tool) files: labeled_lda.py messages: 348720 nosy: xxm priority: normal severity: normal status: open title: 2to3 exception handling versions: Python 3.7 Added file: https://bugs.python.org/file48516/labeled_lda.py ___ Python tracker <https://bugs.python.org/issue37718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37716] 2to3 Accuracy of calculation
New submission from Xinmeng Xia : In Python 2,the output is 1366. After converting by 2to3, the output is 1197.1463275484991 There exists bug in the conversion of 2to3. The output should be consistent for original Python2 code and converted Python3 code. At line 10 of this python file. The code "integer /= 10" is not converted by 2to3. Then I find there is no fixer for division in 2to3,which may lead to inaccuracy of output or even worse results. A possible fix solution is for the division problem of 2to3 I can think is that for division expression such as a/b in Python2, we can add the following type check to check type of a,b as a fix for conversion of 2to3: def DivOp(a, b): if (isinstance(a, int) and isinstance(b, int)): return (a // b) else: return (a / b) and modify a/b as Div(a,b) in converted Python3 file -- components: 2to3 (2.x to 3.x conversion tool) files: euler016.py messages: 348717 nosy: xxm priority: normal severity: normal status: open title: 2to3 Accuracy of calculation type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file48515/euler016.py ___ Python tracker <https://bugs.python.org/issue37716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37715] 2to3 set default encoding
New submission from Xinmeng Xia : There is a bug in lib2to3. When dealing with this project "struts-scan" by 2to3,the following bug will show up. Traceback (most recent call last): File "/home/xxm/Desktop/instrument/datasetpy3/struts-scan/struts-scan.py", line 18, in sys.setdefaultencoding('utf-8') AttributeError: module 'sys' has no attribute 'setdefaultencoding' "sys.setdefaultencoding('utf-8')" is not dealt with by lib2to3. In Python3, there is no such API "setdefaultencoding" for "sys". A possible solution to improve 2to3 is to delete this line "sys.setdefaultencoding('utf-8')" when converting Python2 projects -- components: 2to3 (2.x to 3.x conversion tool) files: struts-scan.py messages: 348716 nosy: xxm priority: normal severity: normal status: open title: 2to3 set default encoding type: compile error versions: Python 3.7 Added file: https://bugs.python.org/file48514/struts-scan.py ___ Python tracker <https://bugs.python.org/issue37715> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37714] 2to3 tab Problems
New submission from Xinmeng Xia : Traceback (most recent call last): File "/home/xxm/Desktop/instrument/datasetpy3/FrisPy/example.py", line 4, in import FrisPy File "/home/xxm/Desktop/instrument/datasetpy3/FrisPy/FrisPy/__init__.py", line 5, in from .disc import * File "/home/xxm/Desktop/instrument/datasetpy3/FrisPy/FrisPy/disc.py", line 7, in from . import coefficient_model File "/home/xxm/Desktop/instrument/datasetpy3/FrisPy/FrisPy/coefficient_model.py", line 34 if isinstance(args[0],np.ndarray): args = args[0] ^ TabError: inconsistent use of tabs and spaces in indentation It seems that it will better to use 4 spaces to replace "tab" in 2to3. -- components: 2to3 (2.x to 3.x conversion tool) files: example.py messages: 348714 nosy: xxm priority: normal severity: normal status: open title: 2to3 tab Problems type: compile error versions: Python 3.7 Added file: https://bugs.python.org/file48513/example.py ___ Python tracker <https://bugs.python.org/issue37714> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com