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 functions. 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 <rep...@bugs.python.org> <http://bugs.python.org/issue28839> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
