BUG: Fix reference count leak in ufunc dtype handling #19289
Conversation
This adds a missing decref to the signature/dtype keyword argument logic in reductions. (The code will change quite a bit after 1.21, but this avoids a reference count leak on 1.21.)
seberg
changed the title
|
OK, (hopefully) all of the others are either expected or false positives due to pytest fixtures I think. |
| @@ -4054,6 +4054,7 @@ PyUFunc_GenericReduction(PyUFuncObject *ufunc, | |||
| } | |||
| Py_INCREF(dtype->singleton); | |||
| otype = dtype->singleton; | |||
| Py_DECREF(dtype); | |||
There was a problem hiding this comment.
A bit of explanation would be good here. I assume that dtype already holds a reference to the singleton member and cleans that up when dtype is destroyed. True? Might read better like
otype = dtype->singleton;
Py_INCREF(otype);
Py_DECREF(dtype);
There was a problem hiding this comment.
Yeah, that is better. This is a bit weird: singleton is guaranteed to exist and dtype can never be destroyed because this is limited to "old-style" DTypes.
This code is simply not yet new-style user DType ready. The whole dance will vanish (or rather: move into legacy-only fallback branches) with the ufunc refactor. Until then, this is a bit awkward because I try to introduce the new logic step-by-step.
`ensure_dtype_nbo()` already increments the reference count, so the INCREF is not necessary here.
|
Thanks Sebastian. |
This adds a missing decref to the signature/dtype keyword argument
logic in reductions.
(The code will change quite a bit after 1.21, but this avoids a
reference count leak on 1.21.)
EDIT: It may take until tonight for me to know whether there is much (or anything) more coming...