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 
don't allocate
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 
stack overflow."

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 
efficient pymalloc.


Python tracker <>
Python-bugs-list mailing list

Reply via email to