This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: libffi & fork
On 04/25/2012 06:32 PM, Gaash Hazan wrote:
>> There is, as far as I can see, only one way to remedy this: allow
>> python to map anonymous memory with both write and execute permission.
>> Then it should work fine.
>
> I believe memory allocation is a service provided by the OS and not by
> the application or interpreter.
The usual problem is a mechanism such as SELinux that is forbidding
Python from mmap()ing PROT_WRITE|PROT_EXEC . If you label the
executable unconfined_execmem_exec_t it may work because then libffi
won't bother with all this multiple maps though a shared file
descriptor business.
> Python does not provide memory allocation service to libffi. In this
> case libffi creates read-write-exec memory block using mmap to a tmp
> file. I guess the problem is common to libff users and it is not
> unique to python.
It's special to Python because Python is the only common libffi client
that forks and then tries to use the closures.
> libffi uses mmap with MAP_SHARED at libffi:closures.c:dlmap(). What
> was the reason for using MAP_SHARED in the first place?
>
> I think MAP_PRIVATE would create the desired behavior of copy-on-write
> when forked. Would that be a proper fix?
No, memory regions that are backed by a real file are always shared
between processes. There is a single file descriptor that
references the block of memory that holds the closures. The only
way you'll get it to work is to create a new file.
Andrew.