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

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

[lfarkas at lfarkas dot org]

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

Levente Farkas <lfarkas at lfarkas dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lfarkas at lfarkas dot org

--- Comment #3 from Levente Farkas <lfarkas at lfarkas dot org> 2012-09-24 15:04:24 UTC ---
are you sure that such and attitude are the right way?

is it a valid c code? if yes and it's failed then it's a bug in glibc.

-- 
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.

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

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> 2012-09-27 16:14:44 UTC ---
CLONE_VM is tricky. See PR 11214.

-- 
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.

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

[lfarkas at lfarkas dot org]

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

--- Comment #5 from Levente Farkas <lfarkas at lfarkas dot org> 2012-09-27 16:32:37 UTC ---
where ulrich also add such a wonderful and useful comment:-)

my simple question: is the above code correct? if yes it's a glibc bug either
implementation or documentation.

-- 
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.

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

[bugdal at aerifal dot cx]

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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> 2012-09-27 18:15:42 UTC ---
The code is not correct. Basically, there's nothing you can safely do with
CLONE_VM unless the child restricts itself to pure computation and direct
syscalls (via sys/syscall.h). If you use any of the standard library, you risk
the parent and child clobbering each other's internal states. You also have
issues like the fact that glibc caches the pid/tid in userspace, and the fact
that glibc expects to always have a valid thread pointer which your call to
clone is unable to initialize correctly because it does not know (and should
not know) the internal implementation of threads.

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.

However, I think it's probably better to just refrain from abusing clone and
use pthread_create the way it was intended to be used, possibly with unshare()
afterwards if you want some threads to have their own signal/fd/etc.
namespaces.

-- 
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.

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

[fweimer at redhat dot com]

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 are on the CC list for the bug.

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

[martinrb at google dot com]

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.

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

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2009-06-22 19:35 -------
If you use clone() you're on your own.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

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

[martinrb at google dot com]

------- Additional Comments From martinrb at google dot com  2009-06-22 19:32 -------
I'm not sure whether this is
- a glibc bug in the implementation of clone()
- a kernel bug in the implementation of the clone syscall
- or simply an unsupported combination of FLAGS.

The fact that the various versions of clone.S explicitly test for
CLONE_VM and CLONE_THREAD and take different action suggest that 
what I'm doing in the test case should work.

I am suspecting a bug in 
sysdeps/unix/sysv/linux/i386/clone.S
but this is deep magic x86 assembly language,
and I'm not competent to debug it.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.