classification
Title: Reference leak in functools.partial constructor in failure case
Type: Stage: resolved
Components: Extension Modules Versions: Python 3.6, Python 3.5
process
Status: closed Resolution: duplicate
Dependencies: Superseder: Type confusion in partial_setstate and partial_call leads to memory corruption
View: 25945
Assigned To: Nosy List: belopolsky, josh.r, serhiy.storchaka
Priority: normal Keywords:

Created on 2016-01-13 22:24 by josh.r, last changed 2016-01-14 07:27 by serhiy.storchaka. This issue is now closed.

Messages (2)
msg258176 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2016-01-13 22:24
Minor bug introduced while implementing the fix for #7830:

In the case where functools.partial is wrapping another functools.partial instance, both of them providing positional arguments, the value nargs is not freed when the tuple concatenation fails and the constructor raises an Exception/returns NULL. Only nargs has the problem (it's a slice of the args passed to the function); pargs is a borrowed reference so there is no leak there. Admittedly, the odds of failure is incredibly low, but best to fix it on principle.

Code link: https://hg.python.org/cpython/file/5a2692911a43/Modules/_functoolsmodule.c#l77

The simplest fix is to add the explicit DECREF in the error path:

        pto->args = PySequence_Concat(pargs, nargs);
        if (pto->args == NULL) {
            pto->kw = NULL;
            Py_DECREF(nargs);  // <-- New
            Py_DECREF(pto);
            return NULL;
        }

All other code paths hit a DECREF later on, no other fixes required. I'd submit a proper patch, but I'm on a new machine and I've got a lot of work to get the repos set up again.
msg258185 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-01-14 07:27
This bug is fixed by more comprehensive patch for issue25945.
History
Date User Action Args
2016-01-14 07:27:01serhiy.storchakasetstatus: open -> closed

superseder: Type confusion in partial_setstate and partial_call leads to memory corruption

nosy: + serhiy.storchaka
messages: + msg258185
resolution: duplicate
stage: resolved
2016-01-13 22:24:30josh.rcreate