This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
[BUG] temporary file-descriptor leak
- From: ÐÐÑÐ ÐÐÑÐÐÐÐÑÐ <socketpair at gmail dot com>
- To: libffi-discuss at sourceware dot org
- Date: Tue, 31 May 2011 22:49:02 +0600
- Subject: [BUG] temporary file-descriptor leak
How to reproduce:
-------------
#!/usr/bin/python
import ctypes
# after os.execl(...) file descriptor from libffi library will leak
---------------
Where is the problem?
Here (closures.c):
----------------------
/* Open a temporary file name, and immediately unlink it. */
static int
open_temp_exec_file_name (char *name)
{
int fd = mkstemp (name);
if (fd != -1)
unlink (name);
return fd;
}
-----------------------
This code does not set O_CLOEXEC, so file will not be closed during
execve(), and fd will leak.
How to fix?
if mkostemp() supported on target platform and O_CLOEXEC is supported in open():
---------------------------
mkstemp(name) -> mkostemp(name, O_CLOEXEC)
(and possibly |O_NOCTTY|O_NOATIME)
---------------------------
if not, we need to use (pthread's???) spinlock in stub function (code
was not tested):
---------------------------
int mkostemp(name, flags)
{
static pthread_mutex_t our_spinlock = PTHREAD_MUTEX_INITIALIZER;
int fd = -1, flags;
pthread_mutex_lock(&our_spinlock);
fd = mkstemp(name);
if (fd == -1)
goto out;
flags = fcntl(fd, F_GETFD);
if (flags == -1)
{
close(fd);
fd = -1;
goto out;
}
flags |= FD_CLOEXEC;
if (fcntl(fd, F_SETFD, flags) == -1)
{
close(fd);
fd = -1;
goto out;
}
out:
pthread_mutex_unlock(&our_spinlock);
return fd;
}
-----------------------------
Why spinlock needed?
because of race-conditions between threads, that calls exec()
(google knows many places where it discussed)
P.S.
Also, fallocate()+mlock() is a good thing against sparse files,
unexpected hangs and SIGBUSes :)
Also, madvice / fadvice is your friends against cache wars
P.P.S.
Why not to open public bug tracker ?!
--
Segmentation fault