[issue38392] Ensure that objects entering the GC are valid

STINNER Victor added the comment: New changeset a5447735c334a041ee2ffdeb5c7e13d7d4502ea2 by Victor Stinner in branch 'master': bpo-38392: Only declare visit_validate() if Py_DEBUG is defined (GH-16689) https://github.com/python/cpython/commit/a5447735c334a041ee2ffdeb5c7e13d7d4502ea2

[issue38392] Ensure that objects entering the GC are valid

Change by STINNER Victor : -- pull_requests: +16275 pull_request: https://github.com/python/cpython/pull/16689 ___ Python tracker ___

[issue38392] Ensure that objects entering the GC are valid

Serhiy Storchaka added the comment: I am sure this will break third-party projects. But I thing that we should not revert this change, as it completely matches the documentation. It is good that it was applied so early at development cycle. Stefan, could you please test Cython and lxml with

[issue38392] Ensure that objects entering the GC are valid

STINNER Victor added the comment: Ok, I pushed a change. Let's see how third party projects like it :-) We still have time to revert it if it causes too many damage. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python

[issue38392] Ensure that objects entering the GC are valid

STINNER Victor added the comment: New changeset 1b1845569539db5c1a6948a5d32daea381f1e35f by Victor Stinner in branch 'master': bpo-38392: PyObject_GC_Track() validates object in debug mode (GH-16615) https://github.com/python/cpython/commit/1b1845569539db5c1a6948a5d32daea381f1e35f

[issue38392] Ensure that objects entering the GC are valid

STINNER Victor added the comment: > It could be possible to do this in backward compatible way. > PyObject_GC_Track() could add the object to the list of new objects (all > objects are already linked in bi-linked list, so it would need to just move > the object to the specified list), and

[issue38392] Ensure that objects entering the GC are valid

STINNER Victor added the comment: > I'm pretty sure you meant nascheme, not nnorwitz. Oops, right :-) -- ___ Python tracker ___

[issue38392] Ensure that objects entering the GC are valid

Serhiy Storchaka added the comment: >From documentation: .. c:function:: void PyObject_GC_Track(PyObject *op) Adds the object *op* to the set of container objects tracked by the collector. The collector can run at unexpected times so objects must be valid while being tracked. This

[issue38392] Ensure that objects entering the GC are valid

Serhiy Storchaka added the comment: It could be possible to do this in backward compatible way. PyObject_GC_Track() could add the object to the list of new objects (all objects are already linked in bi-linked list, so it would need to just move the object to the specified list), and

[issue38392] Ensure that objects entering the GC are valid

Thomas Wouters added the comment: I'm pretty sure you meant nascheme, not nnorwitz. -- nosy: +nascheme, twouters -nnorwitz ___ Python tracker ___

[issue38392] Ensure that objects entering the GC are valid

STINNER Victor added the comment: Pablo, Tim, Neal: what do you think of this idea? -- nosy: +nnorwitz, pablogsal, tim.peters stage: patch review -> ___ Python tracker ___

[issue38392] Ensure that objects entering the GC are valid

Change by STINNER Victor : -- keywords: +patch pull_requests: +16204 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16615 ___ Python tracker ___

[issue38392] Ensure that objects entering the GC are valid

New submission from STINNER Victor : A bug in Python/hamt.c was only discovered 4 months after the code was added to Python: * https://mail.python.org/pipermail/python-dev/2018-June/153857.html * https://bugs.python.org/issue33803 The problem was that an object was tracked by the GC, whereas