[issue42266] LOAD_ATTR cache does not fully replicate PyObject_GetAttr behavior
New submission from Kevin Modzelewski : The problem is that the descriptor-ness of a type-level attribute is only checked at opcache-set time, not at opcache-hit time. $ python3.8 test.py 2 $ ./python --version Python 3.10.0a2+ $ git rev-parse --short HEAD 789359f47c $ ./python test.py 1 -- components: Interpreter Core files: test.py messages: 380370 nosy: Kevin Modzelewski, pablogsal priority: normal severity: normal status: open title: LOAD_ATTR cache does not fully replicate PyObject_GetAttr behavior type: behavior versions: Python 3.10 Added file: https://bugs.python.org/file49568/test.py ___ Python tracker <https://bugs.python.org/issue42266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26718] super.__init__ leaks memory if called multiple times
New submission from Kevin Modzelewski: The super() __init__ function fills in the fields of a super object without checking if they were already set. If someone happens to call __init__ again, the previously-set references will end up getting forgotten and leak memory. For example: import sys print(sys.gettotalrefcount()) sp = super(int, 1) for i in range(10): super.__init__(sp, float, 1.0) print(sys.gettotalrefcount()) -- components: Interpreter Core messages: 263053 nosy: Kevin Modzelewski priority: normal severity: normal status: open title: super.__init__ leaks memory if called multiple times versions: Python 2.7, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26659] slice() leaks memory when part of a cycle
New submission from Kevin Modzelewski: The slice type doesn't participate in GC, which means that if you happen to create a cycle involving a slice, that cycle will never get freed. Here's an example: def f(): l = [] l.append(slice(l)) # Will consume memory without bound: while True: f() This seems pretty hard to trigger accidentally, so it might not be a huge deal -- especially since it seems to have been around for a while. (I only checked 2.7 and trunk though.) I think this could be solved by either having the slice class participate in GC (ie add tp_traverse and tp_clear methods), or maybe doing some type-filtering during slice_new(). -- components: Interpreter Core messages: 262582 nosy: Kevin Modzelewski priority: normal severity: normal status: open title: slice() leaks memory when part of a cycle type: resource usage versions: Python 2.7, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24731] Incorrect assert in str_subtype_new
Kevin Modzelewski added the comment: Awesome, thanks! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24731> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24731] Incorrect assert in str_subtype_new
New submission from Kevin Modzelewski: (Using python 3 terminology) str_subtype_new is the function that creates instances of any subtypes of bytes (ie is called by bytes_new if the requested type is not PyBytes_Type -- looks like this function's name comes from python 2). Its approach is to create a bytes object using the same arguments, and then copy the resulting data into the subclass-instance's memory. It does tmp = bytes_new(PyBytes_Type, args, kwds); [error checking] assert(PyBytes_CheckExact(tmp)); The problem is that bytes_new can return a subclass of bytes, if the argument provides a __bytes__ method that returns a bytes-subtype. For example class MyBytes(bytes): pass class C(object): def __bytes__(self): return MyBytes(bhello world) MyBytes(C()) # fails the assert This doesn't seem to cause any issues other than the failing assert in debug builds; it seems like the assert should just be relaxed from PyBytes_CheckExact to PyBytes_Check since that's enough to guarantee that the upcoming manipulation of the tmp variable is going to be valid. Also, this would match how unicode_subtype_new behaves. This bug also applies to Python 2, since I think the relevant code is the same, though in that case it applies to str instead of bytes. -- components: Interpreter Core messages: 247451 nosy: Kevin Modzelewski priority: normal severity: normal status: open title: Incorrect assert in str_subtype_new versions: Python 2.7, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24731 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
