STINNER Victor added the comment:
I pushed th echange b9c9691c72c5 to replace PyObject_CallFunctionObjArgs() with
_PyObject_CallNoArg() or _PyObject_CallArg1(). These functions are simpler and
memory on the C stack.
I made similar to PyObject_CallFunctionObjArgs() in Python 3.6 to this issue:
don't create a tuple but a small stack allocated on the C stack or allocate
heap memory to pass a C array of PyObject* to _PyObject_FastCall().
Currently, PyObject_CallFunctionObjArgs() uses a small stack for up to 5
positional arguments: it allocates 40 bytes on the C stack.
Serhiy Storchaka: "The problem with C stack overflow is not new, but your patch
may make it worse (I don't know if it actually make it worse)."
I consider that 80 bytes is small enough for a C stack. As I wrote, we can
reduce this "small stack" in the future if somone reports issues.
"Py_EnterRecursiveCall() is used for limiting Python stack. It can't prevent C
I know that the protection is not perfect. It's an heuristic.
I don't even know if it counts Python builtin functions, or only pure Python
But I'm not sure that I understood your comment: do you suggest to use a tuple
and reject this issue? To reduce the size of the small stack? Or to only
allocate memory on the heap memory?
If the issue is the memory allocated on the C stack, maybe we can use a free
list for "stacks" (C array of PyObject*), as done for tuples? I'm not sure that
a free list for PyMem_Malloc()/PyMem_Free() is useful, since it uses our
Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list