New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC #49754
Comments
On Fedora systems, it is invalid to mmap something with PROT_WRITE and Attached is a patch which currently only works if system libffi is used. Note that this also eliminates the malloc_closure code. |
Hm, I don't see any problems with current Python trunk or the |
Currently there is an issue where allow_execstack implies allow_execmem. Try this as root, then repeat your test: |
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: 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: |
Issue bpo-9385 marked as duplicate. |
The libffi library included with Python has been updated in the meantime, so most of the bpo-5504-linux.patch is unneeded now. Here is a new patch, bpo-5504-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. |
bpo-5504-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 |
I do not know why this happens. It works for me, inside my sandbox |
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. |
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 This looks like a different issue from the one above, though. |
Same error on the buildbots, here: |
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 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 |
Please find attached a "fix" for bpo-9662. Some explanation is in order:
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. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: