[issue45758] Crash on Py_DecRef'ing builtin object from previous run
Victor Milovanov added the comment: I think documentation should clarify that. Right now this line in the docs got me thinking that anything with an external strong reference won't be deallocated: "Memory tied up in circular references between objects is not freed." -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue45758> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45758] Crash on Py_DecRef'ing builtin object from previous run
New submission from Victor Milovanov : Trying to Py_DecRef owned reference to builtin "iter" crashes if the reference was alive when runtime was reinitialized. Py_Initialize(); PyObject* builtins = PyEval_GetBuiltins(); PyObject* iter = PyDict_GetItemString(builtins, "iter"); Py_IncRef(iter); Py_Finalize(); // - new run starts, iter should still be alive Py_Initialize(); Py_DecRef(iter); Py_Finalize(); // fails inside PyGC_Collect -> validate_list Related on StackOverflow: https://stackoverflow.com/questions/69890182/is-it-safe-to-call-py-decref-on-an-object-created-before-the-last-py-initializ -- components: C API messages: 405987 nosy: Victor Milovanov priority: normal severity: normal status: open title: Crash on Py_DecRef'ing builtin object from previous run type: crash versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45758> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45266] subtype_clear can not be called from derived types
Victor Milovanov added the comment: To put it differently, if you think in terms of MRO, my custom type's MRO is my_type_clear (from my type), subtype_clear (from PyTypeObject), etc And subtype_clear incorrectly assumes that it is the first entry in the object's MRO list for tp_clear. -- ___ Python tracker <https://bugs.python.org/issue45266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45266] subtype_clear can not be called from derived types
New submission from Victor Milovanov : I am trying to define a type in C, that derives from PyTypeObject. I want to override tp_clear. To do so properly, I should call base type's tp_clear and have it perform its cleanup steps. PyTypeObject has a tp_clear implementation: subtype_clear. Problem is, it assumes the instance it gets is of a type, that does not override PyTypeObject's tp_clear, and behaves incorrectly in 2 ways: 1) it does not perform the usual cleanup, because in this code base = type; while ((baseclear = base->tp_clear) == subtype_clear) the loop condition is immediately false, as my types overrode tp_clear 2) later on it calls baseclear on the same object. But because of the loop above baseclear actually points to my type's custom tp_clear implementation, which leads to reentry to that function (basically a stack overflow, unless there's a guard against it). -- components: C API messages: 402466 nosy: Victor Milovanov priority: normal severity: normal status: open title: subtype_clear can not be called from derived types type: behavior 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/issue45266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14965] super() and property inheritance behavior
Victor Milovanov added the comment: There's a patch attached to this bug. Why is its stage "needs patch"? -- nosy: +Victor Milovanov ___ Python tracker <https://bugs.python.org/issue14965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35235] Access violation on alloc in Windows x86-64 python, pymalloc_alloc
Victor Milovanov added the comment: A bit more information: pool->freeblock for the broken pool looks like this: 0xXYZ? while pool itself looks like this: 0x??XYZ000 -- ___ Python tracker <https://bugs.python.org/issue35235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35235] Access violation on alloc in Windows x86-64 python, pymalloc_alloc
Victor Milovanov added the comment: In my case it always happens in pymalloc_alloc when size == 5, e.g. when accessing usedpools[10]. Specifically freeblock pointer in usedpools[10] is wy off (essentially, seemingly random number looking like 0xX000) where it is supposed to be (e.g. very far from usedpools[10]). Surprisingly, all the other fields in usedpool[10] seem to have normal values. I could not find any place in obmalloc.c where this value would be set, so it seems to be a memory corruption caused by something else. -- ___ Python tracker <https://bugs.python.org/issue35235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35235] Access violation on alloc in Windows x86-64 python, pymalloc_alloc
Victor Milovanov added the comment: This reproduces stably for me when running unit tests in Python.NET project at commit 5e276d9. -- nosy: +Victor Milovanov ___ Python tracker <https://bugs.python.org/issue35235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
