[issue44184] crash on windows invoking flake8

Steve Stagg added the comment: So, for me, the single line from 11159d that causes the problem is this: pprint.py: import dataclasses as _dataclasses Obviously importing dataclasses here is having some side-effect -- ___ Python tracker <ht

[issue44184] crash on windows invoking flake8

Steve Stagg added the comment: I got the same result from a bisect: 11159d2c9d6616497ef4cc62953a5c3cc8454afb -- ___ Python tracker <https://bugs.python.org/issue44

[issue44184] crash on windows invoking flake8

Steve Stagg added the comment: I've found that it's reproducible if you run flake8 on a file that just contains: `a.b` whereas: `a` and `a(b)` don't seem to trigger the error. The object being cleaned up when the segfault appears, seems to be a subclass of ast.AST

[issue44184] crash on windows invoking flake8

Change by Steve Stagg : -- nosy: +stestagg ___ Python tracker <https://bugs.python.org/issue44184> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24258] BZ2File objects do not have name attribute

Steve Stagg added the comment: Please may you add a test that uses "io.BytesIO()" as the filename argument. BytesIO() objects do not have a 'name' attribute -- nosy: +stestagg ___ Python tracker <https://bugs.python.o

[issue37820] Unnecessary URL scheme exists to allow 'URL: reading file in urllib

Steve Stagg added the comment: This appears to have been fixed in python 3: rx.py: import urllib.request print(urllib.request.urlopen('URL:/etc/passwd').read()[:30]) $> python rx.py Traceback (most recent call last): File "rx.py", line 2, in print(urllib.request.urlo

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Steve Stagg added the comment: Sounds great to me (with my approximately zero optimizer experience) At risk of taking this too far, you /could/ add something like: "skip any boolean test of a value _immediately_ following another boolean test, when it has no ..." to this spe

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Steve Stagg added the comment: Oops, sorry, didn't realise there were such rules. The reasoning for me making the change to the title is that that the original PR didn't mention skipping actual condition logic, but does mention skipping unreachable blocks, with the examples provided

[issue42899] Inconsistent elimination of empty blocks by optimizer causes __bool__calls to be skipped in some exception handling scenarios

Steve Stagg added the comment: I re-read the change that introduced this, and the situation is slightly more complex. While the wording is understandably slightly ambiguous, the change talks about the following example: if a: pass else: In this scenario, the compiler is trying

[issue42905] Issue while installing numba inside fastparquet

Steve Stagg added the comment: Hi Sachit I see you raised this issue with the numba library here: https://github.com/numba/numba/issues/6630 I would recommend sticking with the numba issue unless they can confirm there is an issue with core python -- nosy: +stestagg

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Steve Stagg added the comment: I got my and/or logic inverted, but believe the point still stands -- ___ Python tracker <https://bugs.python.org/issue42

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Steve Stagg added the comment: To be super pedantic, as per my understanding of: "6.11 ... The expression x and y first evaluates x; if x is false, its value is returned; otherwise, y is evaluated and the resulting value is returned." The only corner that was prev

[issue42762] infinite loop resulted by "yield"

Steve Stagg added the comment: I don't believe this is a bug. You've discovered a nasty corner-case, but I think it's expected behaviour. There is a PEP open to make this behaviour a bit nicer: https://www.python.org/dev/peps/pep-0533/ The fact that older Python 3.5/6 versions don't get

[issue42899] Possible regression introduced by bpo-42615

Steve Stagg added the comment: Apologies, script should have read: class B: def __bool__(self): print("bool(B)") raise AttributeError("don't do that!") b = B() try: if b: pass except AttributeError: print("GOT ERROR")

[issue42899] Possible regression introduced by bpo-42615

New submission from Steve Stagg : This was raised by Mats Wichmann on the python-dev list. Commit : c71581c7a4192e6ba9a79eccc583aaadab300efa bpo-42615: Delete redundant jump instructions that only bypass empty blocks (GH-23733) appears to have changed the behaviour of the following code

[issue42801] Exception catching function crashes on recursive list

Steve Stagg added the comment: This is fixed by https://github.com/python/cpython/pull/23744 -- nosy: +stestagg ___ Python tracker <https://bugs.python.org/issue42

[issue42762] infinite loop resulted by "yield"

Steve Stagg added the comment: (sorry for spam!) So, this is a retained reference issue. If I change the script to be this: --- import gc DEPTH = 100 def foo(): global DEPTH try: yield except BaseException as e: DEPTH -= 1 if DEPTH <

[issue42762] infinite loop resulted by "yield"

Steve Stagg added the comment: That /is/ weird. I tried a few variations, and it looks like something is being stored on the exception that is stopping the loop behaviour. "except BaseException:" <- infinite loop "except BaseException as e:" <- NO loop

[issue42762] infinite loop resulted by "yield"

Steve Stagg added the comment: Ok, so I now understand a bit more, and think it's not a bug! But explaining it involves some fairly deep thinking about generators. I'll try to explain my reasoning. Let's take a simple example: --- def foo(): try: yield except

[issue42762] infinite loop resulted by "yield"

Steve Stagg added the comment: I'm sorry, I did get a bit confused earlier, I'd mentally switched to context managers. I agree this is a bug, and a kinda weird one! I've narrowed it down to this: If an exception causes flow to exit a for-loop that's powered by a generator, then when

[issue42763] Exposing a race in the "_warnings" resulting Python parser crash

Steve Stagg added the comment: If we take your minimal example (that /sometimes/ crashes), and look at what python is doing: import threading t = threading.Thread(target=1, daemon=True).start() --- The main thread does the following: M1. Startup interpreter, parse code M2. Import

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Steve Stagg added the comment: It's one of those ugly multithreading issues that's really hard to reason about unfortunately. In this case, it's not the size of the loop so much as you've discovered a way to make it very likely that the background thread is doing IO (and holding the IO

[issue42762] infinite loop resulted by "yield"

Steve Stagg added the comment: Behaviour was changed in this commit: --- commit ae3087c6382011c47db82fea4d05f8bbf514265d Author: Mark Shannon Date: Sun Oct 22 22:41:51 2017 +0100 Move exc state to generator. Fixes bpo-25612 (#1773) Move exception state information from frame

[issue42763] Exposing a race in the "_warnings" resulting Python parser crash

Steve Stagg added the comment: Looks like a duplicate of issue42717. Causing a daemonic thread to terminate while doing IO will trigger the above abort -- nosy: +stestagg ___ Python tracker <https://bugs.python.org/issue42

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Steve Stagg added the comment: I think the problem here is that the issue can only really be detected late on during interpreter shutdown. This makes recovery very hard to do. Plus the thread termination has left shared state in an unmanaged condition, so it's super dangerous to re-enter

[issue42716] Segmentation fault in running ast.parse() with large expression size.

Steve Stagg added the comment: fyi, Issue42712, Issue42712, Issue42714, Issue42715, Issue42716 all seem to be variants of the same underlying problem -- ___ Python tracker <https://bugs.python.org/issue42

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Steve Stagg added the comment: Minimal test case: import sys, threading def run(): for i in range(1000): sys.stderr.write(' =.= ') if __name__ == '__main__': threading.Thread(target=run, daemon=True).start() === I think this is expected behaviour. My knowledge

[issue42714] Segmentation fault in running compile() with large expression size.

Steve Stagg added the comment: As with the other ones, PR: https://github.com/python/cpython/pull/23744 stops this from segfaulting. It does however raise a RecursionError: RecursionError: maximum recursion depth exceeded during compilation As per https://bugs.python.org/issue42609

[issue42715] Segmentation fault in running exec() with large expression size.

Steve Stagg added the comment: As with the other issues, the underlying segfault is fixed in PR: https://github.com/python/cpython/pull/23744. It does however raise a RecursionError: RecursionError: maximum recursion depth exceeded during compilation As per https://bugs.python.org

[issue42716] Segmentation fault in running ast.parse() with large expression size.

Steve Stagg added the comment: PR: https://github.com/python/cpython/pull/23744 stops this from segfaulting. It does however raise a RecursionError: RecursionError: maximum recursion depth exceeded during compilation As per https://bugs.python.org/issue42609#msg382910, Serhiy implies

[issue42712] Segmentation fault in running ast.literal_eval() with large expression size.

Steve Stagg added the comment: Confirmed fixed by https://github.com/python/cpython/pull/23744: Traceback (most recent call last): File "/home/sstagg/tmp/fuzztest/cpython/../test.py", line 4, in print(ast.literal_eval("mylist"+"+mylist"*n)) File "/

[issue42712] Segmentation fault in running ast.literal_eval() with large expression size.

Steve Stagg added the comment: Likely duplicate of Issue42609, Probably fixed by bpo-42609 -- nosy: +stestagg ___ Python tracker <https://bugs.python.org/issue42

[issue42652] recursive in finally clause cause Python interpreter crash.

Steve Stagg added the comment: This was also fixed by bpo-42500, in commit 4e7a69bdb6 === user@obsidian ~/t/f/cpython ((93a0ef76…))> git checkout 4e7a69bd^ HEAD is now at 93a0ef7647 Correct return type in Modules/_ssl.c::sslmodule_legacy (GH-23609) + make distclean + CFLAGS=-O0 + ./config

[issue42651] Recursive traceback crashes Python Interpreter

Steve Stagg added the comment: Sorry, previous should have read "Fixes the abort" -- ___ Python tracker <https://bugs.python.org/issue42651> ___ ___

[issue42651] Recursive traceback crashes Python Interpreter

Steve Stagg added the comment: Confirmed that bpo-42500 fixes this traceback, in commit 4e7a69bdb6 Parent commit: user@obsidian ~/t/f/cpython (master)> git checkout 93a0ef7 Note: switching to '93a0ef7'. HEAD is now at 93a0ef7647 Correct return type in Modules/_ssl.c::sslmodule_legacy

[issue42083] PyStructSequence_NewType broken in 3.8

Steve Stagg added the comment: It looks like the segfault was fixed in https://github.com/python/cpython/commit/88c2cfd9ffbcfc43fd1364f2984852a819547d43 as part of https://bugs.python.org/issue41832. The code in this area of typeobject.c looks a bit different, now, but the backport seems

[issue42609] Eval with too high string multiplication crashes newer Python versions

Steve Stagg added the comment: In python 3.7/8, It's a stack overflow in the constant folding code. On master, the overflow seems to come out of validate_expr.c. * thread #1, name = 'python3', stop reason = signal SIGSEGV: invalid address (fault address: 0x7f7feff8) frame #0

[issue42609] Eval with too high string multiplication crashes newer Python versions

Steve Stagg added the comment: Looks like it was introduced by https://github.com/python/cpython/commit/7ea143ae795a9fd57eaccf490d316bdc13ee9065: bpo-29469: Move constant folding to AST optimizer (GH-2858) -- nosy: +stestagg ___ Python tracker

[issue42540] Debug pymalloc crash when using os.fork() [regression]

Steve Stagg added the comment: So, I'm not an allocator/init/teardown expert, but it looks like: When you fork, PyRuntimeState creates a new mutex, explicitly using the default allocator (without the debug allocator active).. #ifdef HAVE_FORK /* This function is called from

[issue42540] Debug pymalloc crash when using os.fork() [regression]

Steve Stagg added the comment: Something seems to be: breaking alignment, changing the allocator used, or trashing that memory. In my case, the address of the mutex is: 0x5603a330 (*1) below and the surrounding memory: 0x5603a310: n\0\0\03\0\0\0\0\0\0\0(*2)\xdd\xdd\xdd\xdd\xdd\xdd

[issue42540] Debug pymalloc crash when using os.fork() [regression]

Steve Stagg added the comment: Reproducible on master, but doesn't occur with a debug build. My configure: > ./configure --prefix=$PREFIX --exec-prefix=$EPREFIX > --cache-file=../config.cache --without-ensurepip > /dev/null > PYTHONMALLOC=pymalloc_debug $EPREFIX/bin/python

[issue41367] Popen Timeout raised on 3.6 but not on 3.8

Steve Stagg added the comment: Joan, is that your *actual* password in the example code? If so, I'd recommend changing it wherever you've used it. -- nosy: +stestagg ___ Python tracker <https://bugs.python.org/issue41

[issue41335] free(): invalid pointer in list_ass_item() in Python 3.7.3

Steve Stagg added the comment: It's possible that RPi.GPIO (or another C extension) is mis-managing reference counts, resulting in it freeing or trying to free an object at the wrong time. If that object is a common value, or the branch that causes the refcount issue is uncommon, it may

[issue41337] strangnedd with the parser

Steve Stagg added the comment: This appears to be a bug with the google colab site. For whatever reason, if you try to evaluate a statement that is a line with a leading comma (afaik, never valid python), then colab does something wierd by wrapping the arguments in quotes, and evaluating

[issue40965] Segfault when importing unittest module via C API

Steve Stagg added the comment: Fix was here: a75e730075 bpo-40294: Fix _asyncio when module is loaded/unloaded multiple times (GH-19542) Backport commit was: 6b0ca0aeab04d7b7b54086248ca9d5e70f770f2f >From my end, the issue seems to be resovled on tag v.3.

[issue40965] Segfault when importing unittest module via C API

Steve Stagg added the comment: I was able to reproduce, follows is the raw LLDB output, I don't think this fails on master, will try some bisecting: * thread #1, name = 'runtest', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x77079ae7

[issue40965] Segfault when importing unittest module via C API

Steve Stagg added the comment: This appears to have been introduced in 13915a3100 bpo-36356: Fix memory leak in _asynciomodule.c (GH-16598). Cannot reproduce on master -- ___ Python tracker <https://bugs.python.org/issue40

[issue41060] `with a as b` segfault in new peg parser

Steve Stagg added the comment: Appears to have been introduced by: bpo-40334: Produce better error messages on invalid targets (GH-20106) 01ece63d42b830df106948db0aefa6c1ba24416a -- ___ Python tracker <https://bugs.python.org/issue41

[issue41060] `with a as b` segfault in new peg parser

New submission from Steve Stagg : Hi Fuzzing found the following: $ ./python/bin/python3 Python 3.10.0a0 (heads/master:eb0d5c38de, Jun 20 2020, 21:35:36) [Clang 10.0.0 ] on linux Type "help", "copyright", "credits" or "license" for more information. >

[issue40904] Segfault from new PEG parser handling yield withing f-strings

New submission from Steve Stagg : The following command causes python to segfault: $ echo "f'{yield}'" | python/bin/python3 Bisect tracked this down to: c5fc15685202cda73f7c3f5c6f299b0945f58508 (bpo-40334: PEP 617 implementation: New PEG parser for CPython (GH-19503)) The ille

[issue40903] Segfault in new PEG parser

New submission from Steve Stagg : The input `p=p=` causes python 3.10 to crash. I bisected the change, and the behavior appears to have been introduced by 16ab07063cb564c1937714bd39d6915172f005b5 (bpo-40334: Correctly identify invalid target in assignment errors (GH-20076) ) Steps