Reproducible in 2.7 and tip: [meadori@motherbrain cpython]$ ./python Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct 3 2011, 21:47:04) [GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> NARGS = 2 ** 20 >>> proto = CFUNCTYPE(None, *(c_int,) * NARGS) >>> def func(*args): ... return (1, "abc", None) ... >>> cb = proto(func) >>> cb(*(1,) * NARGS) Segmentation fault (core dumped)

As mentioned in issue12881, this issue is a result of an unbounded 'alloca' call that trashes the stack.

Right, alloca() could be replaced by some malloc(), but is it really useful? After all, when a C function calls back to Python, all arguments needs to be pushed to the stack anyway.

On Wed, Nov 30, 2011 at 6:20 AM, Amaury Forgeot d'Arc <report@bugs.python.org> wrote: > Right, alloca() could be replaced by some malloc(), but is it really useful?  After all, when a C function calls back to Python, all arguments needs to be > pushed to the stack anyway. The case is somewhat pathological. However, there are *four* 'alloca' calls in '_ctypes_callproc', three of which are proportional to 'argcount'. And as you point out there is an additional stack allocation inside of 'libffi' when the callback is actually called (also using 'alloca'). I see two reasons switching to 'malloc' might be beneficial: (1) by shifting some of the allocation to dynamic allocation we may reduce the chance that we blow the stack at all. Keep in mind that this gets more likely if the C ffi function is called from a deep in a call tree and *not* necessarily with just a huge number of parameters. (2) if resources are exhausted, then we can exit more gracefully. Out of dynamic memory errors can actually be handled as opposed to an 'alloca' call that ends up allocating more than is left. That being said, if this does get changed it is low priority.

Is there really an use case where you need 2 ** 20 (1,048,576) arguments? If yes, I'm not against the torture in this case :-) If no, why not raising an error if there are too many arguments? E.g. limit to 1,024 arguments or maybe just 10?

On Thu, Dec 1, 2011 at 2:11 AM, STINNER Victor <report@bugs.python.org> wrote: > Is there really an use case where you need 2 ** 20 (1,048,576) arguments? If yes, I'm not against the torture in this case :-) Not very likely :-) However, the segfault can occur with less arguments in low stack space situations (e.g. deep callstack). > If no, why not raising an error if there are too many arguments? E.g. limit to 1,024 arguments or maybe just 10? That is certainly an option.

The issue continues in python 3.8.2.

I suggest to raise an exception if it's called with more than 1024 arguments.

 New changeset 29a1384c040d39659e7d01f1fd7b6eb71ef2634e by Sean Gillespie in branch 'master': bpo-13097: ctypes: limit callback to 1024 arguments (GH-19914) https://github.com/python/cpython/commit/29a1384c040d39659e7d01f1fd7b6eb71ef2634e 

 New changeset 788d7bfe189e715eab3855c20ea5d6da0d8bed70 by Miss Islington (bot) in branch '3.9': bpo-13097: ctypes: limit callback to 1024 arguments (GH-19914) https://github.com/python/cpython/commit/788d7bfe189e715eab3855c20ea5d6da0d8bed70 

 New changeset 1c4dcafd0b025e771f4dbd7197d0b5f263c9cb54 by Miss Islington (bot) in branch '3.7': bpo-13097: ctypes: limit callback to 1024 arguments (GH-19914) https://github.com/python/cpython/commit/1c4dcafd0b025e771f4dbd7197d0b5f263c9cb54 

 New changeset a285af7e626d1b81cf09f8b2bf7656f100bc1237 by Miss Islington (bot) in branch '3.8': bpo-13097: ctypes: limit callback to 1024 arguments (GH-19914) https://github.com/python/cpython/commit/a285af7e626d1b81cf09f8b2bf7656f100bc1237 

Thanks Meador Inge for the bug report and thanks Sean Gillespie for the fix! It just took 9 years to fix this corner case ;-) Copy of the comment on the PR: https://github.com/python/cpython/pull/19914#pullrequestreview-419331432 I tried to rewrite _ctypes_callproc() to use PyMem_Malloc() instead of alloca(), but it's quite complicated. There are 3 arrays with a length of argcount items: args, avalues, atypes. Moreover, resbuf is also allocated with alloca(). When using PyMem_Malloc(), error handling is much more complicated. I also tried to restrict the overall usage of stack memory to 4096 bytes (size of one page on x86), but users would be surprised by CTYPES_MAX_ARGCOUNT value. I would say that raising an exception is better than crashing for a lot of arguments. If someone is blocked by this new limitation, in that case we can revisit the PyMem_Malloc() idea.