Changes by Florent Xicluna florent.xicl...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5504
___
___
Ronald Oussoren ronaldousso...@mac.com added the comment:
Fixing the alloc_closure error is easy enough:
Index: ../setup.py
===
--- ../setup.py (revision 84528)
+++ ../setup.py (working copy)
@@ -1653,7 +1653,9 @@
Åukasz Langa luk...@langa.pl added the comment:
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
Ronald Oussoren ronaldousso...@mac.com added the comment:
Ł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
Sridhar Ratnakumar sridh...@activestate.com added the comment:
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:
Mark Dickinson dicki...@gmail.com added the comment:
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
--
___
Python tracker rep...@bugs.python.org
Thomas Heller thel...@ctypes.org added the comment:
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
Antoine Pitrou pit...@free.fr added the comment:
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
Antoine Pitrou pit...@free.fr added the comment:
Correction: the revert was done in r83926.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5504
___
Thomas Heller thel...@ctypes.org added the comment:
issue5504-py27-2.patch is the updated patch that now also works on Windows.
--
Added file: http://bugs.python.org/file18439/issue5504-py27-2.patch
___
Python tracker rep...@bugs.python.org
Thomas Heller thel...@ctypes.org added the comment:
Fixed in rev 83836 (release27-maint branch) and rev. 83837 (py3k branch).
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5504
Łukasz Langa luk...@langa.pl added the comment:
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
--
nosy: +lukasz.langa
Changes by Antoine Pitrou pit...@free.fr:
--
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5504
___
___
Python-bugs-list
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5504
___
___
Python-bugs-list
Thomas Heller thel...@ctypes.org added the comment:
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
Mark Lawrence breamore...@yahoo.co.uk added the comment:
Could someone with linux experience please review the patch.
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5504
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
title: ctypes should work with systems where mmap can't be PROT_WRITE and
PROT_EXEC - ctypes should work with systems where mmap can't be PROT_WRITE and
PROT_EXEC
versions: +Python 2.7,
Dave Malcolm dmalc...@redhat.com added the comment:
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.1content-type=text%2Fplainview=co
It doesn't
Changes by Brian Curtin cur...@acm.org:
--
keywords: +needs review
priority: - normal
stage: - patch review
type: crash - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5504
___
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5504
___
___
Python-bugs-list
Thomas Heller thel...@ctypes.org added the comment:
Try this as root, then repeat your test:
semanage boolean -m --off allow_execstack
Ok, I can reproduce the problem now. Thanks!
--
title: ctypes should work with systems where mmap can't be PROT_WRITE and
PROT_EXEC - ctypes should
Thomas Heller thel...@ctypes.org added the comment:
Here is a patch for Python trunk (linux only).
--
Added file: http://bugs.python.org/file13897/issue5504.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5504
Thomas Heller thel...@ctypes.org added the comment:
Hm, I don't see any problems with current Python trunk or the
release26-maint branch, on a Fedora 10 system.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5504
Adam Goode a...@spicenitz.org added the comment:
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.
New submission from Adam Goode a...@spicenitz.org:
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
25 matches
Mail list logo
