You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In _abcmodule_exec(), when _abc_data type is created, it's created with refcnt=3:
1 strong reference (normal)
+1 ref from tp_dict['__new__'] slot
+1 ref from tp_mro
type_traverse() visits tp_dict and tp_mro, so it's fine.
In Py_EndInterpreter(), PyInterpreterState_Clear() clears os.register_atfork() callbacks which were one of the last references to _abc_data type. The first call to _PyGC_CollectNoFail() destroys _abc_data *instances* but not the _abc_data type.
I'm not sure why Py_VISIT(Py_TYPE(self)) is needed. Maybe it's a regression caused by commit 364f0b0 of bpo-35810.
It sems like the GC doesn't take in account that instances of types allocated on the heap (if type->tp_flags has the Py_TPFLAGS_HEAPTYPE flag) hold a strong refeference to the type (PyObject.ob_type).
I created bpo-40217: "The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type".
Activity
vstinner commentedon Apr 2, 2020
New changeset 53e4c91 by Dong-hee Na in branch 'master':
bpo-40077: Convert _abc module to use PyType_FromSpec() (GH-19202)
53e4c91
This change introduced a reference leak:
$ ./python -m test -R 3:3 test_threading -m test.test_threading.SubinterpThreadingTests.test_threads_join_2 0:00:00 load avg: 1.52 Run tests sequentially 0:00:00 load avg: 1.52 [1/1] test_threading beginning 6 repetitions 123456 ...... test_threading leaked [19, 19, 19] references, sum=57 test_threading leaked [12, 12, 12] memory blocks, sum=36 test_threading failed== Tests result: FAILURE ==
1 test failed:
test_threading
Total duration: 768 ms
Tests result: FAILURE
vstinner commentedon Apr 2, 2020
Attached test_leak.py is enough to reproduce the leak. It's related to subinterpreters and the _abc module.
vstinner commentedon Apr 2, 2020
I'm not sure why, but trigger explicitly a second GC collection fix the issue.
corona10 commentedon Apr 2, 2020
FYI,
first gc collect 772
secondary gc collect 4
corona10 commentedon Apr 3, 2020
gc: collectable <type 0x7fc033c3cbd0>
gc: collectable <dict 0x104d79830>
gc: collectable <tuple 0x104d725a0>
gc: collectable <builtin_function_or_method 0x104d79890>
is not collected for the first time.
corona10 commentedon Apr 3, 2020
Running
from abc import ABCMeta
on the subinterpreter makes same size of leak.
vstinner commentedon Apr 7, 2020
New changeset 9cc3ebd by Victor Stinner in branch 'master':
bpo-40149: Implement traverse in _abc._abc_data (GH-19412)
9cc3ebd
vstinner commentedon Apr 7, 2020
In _abcmodule_exec(), when _abc_data type is created, it's created with refcnt=3:
type_traverse() visits tp_dict and tp_mro, so it's fine.
In Py_EndInterpreter(), PyInterpreterState_Clear() clears os.register_atfork() callbacks which were one of the last references to _abc_data type. The first call to _PyGC_CollectNoFail() destroys _abc_data *instances* but not the _abc_data type.
The following patch works around the issue:
$ ./python -m test -R 3:3 test_threading -m test.test_threading.SubinterpThreadingTests.test_threads_join_2 (...) Tests result: SUCCESSI'm not sure why Py_VISIT(Py_TYPE(self)) is needed. Maybe it's a regression caused by commit 364f0b0 of bpo-35810.
It sems like the GC doesn't take in account that instances of types allocated on the heap (if type->tp_flags has the Py_TPFLAGS_HEAPTYPE flag) hold a strong refeference to the type (PyObject.ob_type).
I created bpo-40217: "The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type".
corona10 commentedon Apr 7, 2020
Wow Thank you for the summary :)
vstinner commentedon Apr 7, 2020
Pablo told me that this change is not correct: the overriden traverse function must call PyType_Type.tp_traverse (parent method).
vstinner commentedon Apr 27, 2020
This issue is now fixed. I tested manually: I confirm that it does fix the test_threading leak, so I close the issue.
$ ./python -m test -R 3:3 test_threading (...) == Tests result: SUCCESS ==1 test OK.
Total duration: 1 min 14 sec
Tests result: SUCCESS