> There are also a few fingers pointing in the direction of weakref_ref,
> e.g.
>
> ==28827== 520 bytes in 14 blocks are possibly lost in loss record 48 of 106
> ==28827== at 0x400481B4: malloc (vg_clientfuncs.c:100)
> ==28827== by 0x8099519: _PyObject_GC_New (Modules/gcmodule.c:868)
> ==28827== by 0x8067BA5: PyWeakref_NewRef (Objects/weakrefobject.c:37)
> ==28827== by 0x8066119: add_subclass (Objects/typeobject.c:2249)
> ==28827== by 0x8061F29: PyType_Ready (Objects/typeobject.c:2219)
> ==28827== by 0x80605A8: type_new (Objects/typeobject.c:1280)
> ==28827== by 0x805EDA4: type_call (Objects/typeobject.c:183)
> ==28827== by 0x80ABB0C: PyObject_Call (Objects/abstract.c:1688)
> ==28827== by 0x807A34F: PyEval_CallObjectWithKeywords (Python/ceval.c:3058)
> ==28827== by 0x80AB0C6: PyObject_CallFunction (Objects/abstract.c:1679)
>
> Of course many of these could be caused by a single leak that drops a
> pointer to a container -- then everything owned by that container is
> also leaked.
This one seems simple:
diff -c -c -r2.126.4.25 typeobject.c
*** typeobject.c 11 Oct 2002 00:22:22 -0000 2.126.4.25
--- typeobject.c 18 Oct 2002 00:50:31 -0000
***************
*** 2249,2256 ****
while (--i >= 0) {
ref = PyList_GET_ITEM(list, i);
assert(PyWeakref_CheckRef(ref));
! if (PyWeakref_GET_OBJECT(ref) == Py_None)
! return PyList_SetItem(list, i, new);
}
i = PyList_Append(list, new);
Py_DECREF(new);
--- 2249,2259 ----
while (--i >= 0) {
ref = PyList_GET_ITEM(list, i);
assert(PyWeakref_CheckRef(ref));
! if (PyWeakref_GET_OBJECT(ref) == Py_None) {
! i = PyList_SetItem(list, i, new);
! Py_DECREF(new);
! return i;
! }
}
i = PyList_Append(list, new);
Py_DECREF(new);
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4