[issue26811] segfault due to null pointer in tuple

[STINNER Victor]

STINNER Victor added the comment:

Serhiy: "Ah, yes, 5dbf3d932a59 partially fixed this optimization."

Since we already talking about hacks, another hack is to hide this private tuple from the GC using _PyObject_GC_UNTRACK(): see attached property_descr_get_gc_untrack.patch.

Note: I dislike my own patch :-D


Serhiy: "661cdbd617b8 can cause problems with recursion and with cached getters. I suggest to revert it."

Even if I don't understand the issue, I concur that the micro-optimization must be reverted. A micro-optimization must not introduce any behaviour change nor segfault :-)


Raymond Hettinger: "Serhiy, I'll thinking the whole optimization ought to be reverted as being too tricky and error-prone for the small benefit.  A less aggressive approach would be to have the tuple save a valid object (such as None) instead of NULL.  What do you think?"

PyEval_EvalCodeEx() accepts a C array of PyObject* for function arguments, it's used by fast_function() in Pythn/ceval.c. Maybe a new C function can be designed to call a function: it would uses PyEval_EvalCodeEx() to call functions implemented in Python, or create the tuple for functions implemented in C.

It looks like the issue #23910 which introduced the optimization was created for functions implemented in C. So I don't know it's acceptable. But it would be safer and more generic, no?

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file42546/property_descr_get_gc_untrack.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________