This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/10311] clone(CLONE_VM) fails with pthread_getattr_np on i386
- From: "martinrb at google dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Fri, 28 Sep 2012 00:57:46 +0000
- Subject: [Bug nptl/10311] clone(CLONE_VM) fails with pthread_getattr_np on i386
- Auto-submitted: auto-generated
- References: <bug-10311-131@http.sourceware.org/bugzilla/>
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.