[Bug nptl/10311] clone(CLONE_VM) fails with pthread_getattr_np on i386

["martinrb at google dot com" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=10311

--- Comment #8 from Martin Buchholz <martinrb at google dot com> 2012-09-28 00:57:46 UTC ---
The GPL code to allow a (big) Java process to start (small) subprocesses
without a momentary doubling of memory requirements can be found here:
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/d94613ac03d8/src/solaris/native/java/lang/UNIXProcess_md.c

vfork seems to have worked well for years.  As I wrote:

/*
 * There are 3 possible strategies we might use to "fork":
 *
 * - fork(2).  Very portable and reliable but subject to
 *   failure due to overcommit (see the documentation on
 *   /proc/sys/vm/overcommit_memory in Linux proc(5)).
 *   This is the ancient problem of spurious failure whenever a large
 *   process starts a small subprocess.
 *
 * - vfork().  Using this is scary because all relevant man pages
 *   contain dire warnings, e.g. Linux vfork(2).  But at least it's
 *   documented in the glibc docs and is standardized by XPG4.
 *   http://www.opengroup.org/onlinepubs/000095399/functions/vfork.html
 *   On Linux, one might think that vfork() would be implemented using
 *   the clone system call with flag CLONE_VFORK, but in fact vfork is
 *   a separate system call (which is a good sign, suggesting that
 *   vfork will continue to be supported at least on Linux).
 *   Another good sign is that glibc implements posix_spawn using
 *   vfork whenever possible.  Note that we cannot use posix_spawn
 *   ourselves because there's no reliable way to close all inherited
 *   file descriptors.
 *
 * - clone() with flags CLONE_VM but not CLONE_THREAD.  clone() is
 *   Linux-specific, but this ought to work - at least the glibc
 *   sources contain code to handle different combinations of CLONE_VM
 *   and CLONE_THREAD.  However, when this was implemented, it
 *   appeared to fail on 32-bit i386 (but not 64-bit x86_64) Linux with
 *   the simple program
 *     Runtime.getRuntime().exec("/bin/true").waitFor();
 *   with:
 *     #  Internal Error (os_linux_x86.cpp:683), pid=19940, tid=2934639536
 *     #  Error: pthread_getattr_np failed with errno = 3 (ESRCH)
 *   We believe this is a glibc bug, reported here:
 *     http://sources.redhat.com/bugzilla/show_bug.cgi?id=10311
 *   but the glibc maintainers closed it as WONTFIX.
 *
 * Based on the above analysis, we are currently using vfork() on
 * Linux and fork() on other Unix systems, but the code to use clone()
 * remains.
 */



On Thu, Sep 27, 2012 at 11:28 AM, fweimer at redhat dot com <
sourceware-bugzilla@sourceware.org> wrote:

>
> http://sourceware.org/bugzilla/show_bug.cgi?id=10311
>
> Florian Weimer <fweimer at redhat dot com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |fweimer at redhat dot com
>
> --- Comment #7 from Florian Weimer <fweimer at redhat dot com> 2012-09-27
> 18:28:37 UTC ---
> (In reply to comment #6)
> > I know my warning not to call even async-signal-safe functions in libc,
> and to
> > make all syscalls manually, seems extreme, but I don't see any way
> around it
> > given the above issues. Perhaps glibc could document a set of
> "clone_vm-safe"
> > functions that can be used in the child after cloning with CLONE_VM
> without
> > having to worry that they will access internal libc state or need a valid
> > thread pointer.
>
> errno and cancellation support require working TLS, so the set of safe
> functions would be quite small and probably not that useful.
>
> If this functionality is desired, an interface for setting up a working
> libc
> environment in the quasi-subprocess would likely be more useful.
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.