homepage

On Fedora systems, it is invalid to mmap something with PROT_WRITE and
PROT_EXEC. libffi has been updated to support this, but ctypes has not
been updated to use this new functionality.
Attached is a patch which currently only works if system libffi is used.
Though the embedded version of libffi is new enough, it is missing the
allocation and free functions. I know how I would update the ctypes
libffi/ directory (add the alloc/free files), but not sure about the
other libffi directories (darwin, arm_wince, msvc, osx). I suppose those
would all need to be upgraded, or perhaps even made to use the standard
libffi instead of special forks of it.
Note that this also eliminates the malloc_closure code.

Hm, I don't see any problems with current Python trunk or the
release26-maint branch, on a Fedora 10 system.

Currently there is an issue where allow_execstack implies allow_execmem.
Even though allow_execmem is default to off, allow_execstack is default
to on. If this issue is fixed, or if the administrator sets
allow_execstack to off, ctypes will fail.
Try this as root, then repeat your test:
semanage boolean -m --off allow_execstack

> Try this as root, then repeat your test:
> semanage boolean -m --off allow_execstack
Ok, I can reproduce the problem now. Thanks!

Here is a patch for Python trunk (linux only).

Could someone with linux experience please review the patch.

FWIW, the patch for this that I'm currently applying to Fedora's python 2.7 rpms can be seen at:
http://cvs.fedoraproject.org/viewvc/devel/python/python-2.7rc1-ctypes-noexecmem.patch?revision=1.1&content-type=text%2Fplain&view=co
It doesn't contain the rebase of libffi (since we use the system copy of libffi in our builds), but otherwise I believe that it's essentially equivalent to:
http://bugs.python.org/file13897/issue5504-linux.patch
albeit rebased to 2.7, taking into account the whitespace cleanup changes.

Issue #9385 marked as duplicate.

The libffi library included with Python has been updated in the meantime, so most of the issue5504-linux.patch is unneeded now.
Here is a new patch, issue5504-py27.patch, against the current release27-maint branch. Seems it is exactly the same as the fedora patch that dmalcolm mentioned.
If someone can test the patch on an selinux system it would be great.

issue5504-py27-2.patch is the updated patch that now also works on Windows.

Fixed in rev 83836 (release27-maint branch) and rev. 83837 (py3k branch).

Thomas, it seems this change doesn't work for py3k. Buildbots complain and my working copy does as well.
Example:
http://www.python.org/dev/buildbot/all/builders/x86%20gentoo%203.1/builds/990 

> Thomas, it seems this change doesn't work for py3k. Buildbots complain and my working copy does as well.
> 
> Example:
> 
> http://www.python.org/dev/buildbot/all/builders/x86%20gentoo%203.1/builds/990
I do not know why this happens. It works for me, inside my sandbox
as well as on a newly checkout copy.
Anyway, I'm not able to fix it since I'm going to holidays.

> I do not know why this happens.
The failure is in 3.1, and the reason is quite obvious: the patch relies on libffi/src/closures.c, which doesn't exist in the 3.1 copy of libffi.
I've reverted your commit in r83924, since you say you won't be able to look at it immediately. Unfortunately, this also reverts the refcounting fix.

Correction: the revert was done in r83926.

Since r83837, the py3k _ctypes module fails to build on my OS X 10.6 machine:
*** WARNING: renaming "_ctypes" since importing it failed: dlopen(build/lib.macosx-10.6-x86_64-3.2-pydebug/_ctypes.so, 2): Symbol not found: _ffi_closure_alloc
 Referenced from: /Users/dickinsm/python/svn/py3k/build/lib.macosx-10.6-x86_64-3.2-pydebug/_ctypes.so
 Expected in: flat namespace
 in /Users/dickinsm/python/svn/py3k/build/lib.macosx-10.6-x86_64-3.2-pydebug/_ctypes.so
This looks like a different issue from the one above, though.

Same error on the buildbots, here:
http://www.python.org/dev/buildbot/3.x/builders/PPC%20Leopard%203.x/builds/288/steps/compile/logs/stdio 

Like Mark, I too see an error with ctypes due to this change:
*** WARNING: renaming "_ctypes" since importing it failed: dlopen(build/lib.macosx-10.5-intel-3.2/_ctypes.so, 2): Symbol not found: _ffi_closure_alloc
 Referenced from: /Users/sridharr/as/apy/branches/32a1ssl1/build/pyhg_branches_py3k-macosx-hgtip32/python/build/lib.macosx-10.5-intel-3.2/_ctypes.so
 Expected in: flat namespace
 in /Users/sridharr/as/apy/branches/32a1ssl1/build/pyhg_branches_py3k-macosx-hgtip32/python/build/lib.macosx-10.5-intel-3.2/_ctypes.so
MacOSX 10.6 | built with 10.5 SDK | i386 and x86_64 arch | ActivePython 3.2 internal build

Fixing the alloc_closure error is easy enough:
Index: ../setup.py
===================================================================
--- ../setup.py	(revision 84528)
+++ ../setup.py	(working copy)
@@ -1653,7 +1653,9 @@
 '_ctypes/callbacks.c',
 '_ctypes/callproc.c',
 '_ctypes/stgdict.c',
- '_ctypes/cfield.c']
+ '_ctypes/cfield.c',
+ '_ctypes/malloc_closure.c',
+ ]
 depends = ['_ctypes/ctypes.h']
 
 if sys.platform == 'darwin':
That's not enough to make it possible to build ctypes on OSX though, I now get the same error for a different symbol:
*** WARNING: renaming "_ctypes" since importing it failed: dlopen(build/lib.macosx-10.6-fat-3.2/_ctypes.so, 2): Symbol not found: _ffi_prep_closure_loc
 Referenced from: /Users/ronald/Projects/python/python-3.x/build/build/lib.macosx-10.6-fat-3.2/_ctypes.so
 Expected in: flat namespace
 in /Users/ronald/Projects/python/python-3.x/build/build/lib.macosx-10.6-fat-3.2/_ctypes.so

Please find attached a "fix" for #9662. Some explanation is in order:
- the Windows, Linux and OS X implementations of FFI included in the SVN are different in terms of maturity
- Thomas originally when fixing #5504 used a bit of functionality regarding closures that wasn't there in the Windows and OS X versions
- he did some dirty hacking on the Windows version to make it work: changed the ffi_prep_closure function header to ffi_prep_closure_loc (leaving the old implementation) and introduced names for ffi_closure_alloc and ffi_closure_free
- he didn't touch the OS X version so it failed
I did more-less the same thing but in case of OS X we have many ffi_prep_closure implementations for different archs so I simply did an #ifdef in the place ffi_prep_closure is used.
I think a better solution ultimately would be to update all implementation to FFI 3.0.9 and be done with it. Still, the current patch works for me.

Łukasz' patch fixes the issue for me.
As the patch only affects code-paths used on OSX (patches to the libffi version for OSX and an #ifdef that makes OSX use ffi_prep_closure instead of ffi_prep_closure_loc) I intend to commit the patch later today to be able to build a working copy of the OSX installer for the next alpha release.
I'm at best -0 on moving all platforms to libffi 3.0.9. 'libffi_osx' works properly on OSX and I have no idea whether all changes in that fork of libffi have been merged back into the canonical version.