STINNER Victor <[email protected]> added the comment:
> I don't understand how the function ended up with func_code=NULL. That
> shouldn't be a valid function to call, IMO. Do you have any info on how the
> function ended up in that state?
It doesn't seem possible to create a function with func_code=NULL, nor to set
func_code to NULL. func_code can be be set to NULL by func_clear() which is
called by func_dealloc().
I bet that func_clear() has been called since most func fields are set to NULL,
which is consistent with:
static int
func_clear(PyFunctionObject *op)
{
Py_CLEAR(op->func_code);
Py_CLEAR(op->func_globals);
Py_CLEAR(op->func_module);
Py_CLEAR(op->func_name);
Py_CLEAR(op->func_defaults);
Py_CLEAR(op->func_kwdefaults);
Py_CLEAR(op->func_doc);
Py_CLEAR(op->func_dict);
Py_CLEAR(op->func_closure);
Py_CLEAR(op->func_annotations);
Py_CLEAR(op->func_qualname);
return 0;
}
The question is how is it possible that a deallocated function is still
accessed? It smells like a borrowed reference somewhere in the call chain.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue38006>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
