[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
priority: normal
severity: normal
status: open
title: Long paths in imp.load_dynamic() lead to segfault
type: crash
versi
[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 1966307 /
[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, , , 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
