[Bug libc/6910] New: getpid() wrong in child's signal handler after clone()

[Bug libc/6910] New: getpid() wrong in child's signal handler after clone()

[mtk dot manpages at gmail dot com]

As at glibc 2.8, glibc caching of PIDs for getpid() means that if a signal is
delivered to the child soon after a clone() (i.e.,  before the child has a
chance to update the cache), then a call to getpid() within the signal handler
in the child returns the wrong value.   

To test this, the attached program creates a child process that continuously
sends a SIGQUIT signal to the process group.  Meanwhile the parent loops
creating children that sleep for a moment, and then terminate.  In that time,
the SIGQUIT handler will be invoked in the child.  If the getpid() cache has not
yet been updated, then it will (occasionally) happen that the values returned by
glibc's getpid() and a raw syscall(SYS_getpid) will not match.  When that
occurs, the child prints a message noting the mismatch.

If this program is invoked with any command-line argument, then it uses fork()
instead of clone().  This can be used to show that the problem does not occur
for fork().

-- 
           Summary: getpid() wrong in child's signal handler after clone()
           Product: glibc
           Version: 2.8
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: mtk dot manpages at gmail dot com
                CC: glibc-bugs at sources dot redhat dot com


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

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

[Bug libc/6910] getpid() wrong in child's signal handler after clone()

[mtk dot manpages at gmail dot com]

------- Additional Comments From mtk dot manpages at gmail dot com  2008-09-22 11:47 -------
Created an attachment (id=2959)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2959&action=view)
Test program

When running this program on glibc 2.8 on an i386 system, I see output such as
the following:

$ ./clone_getpid_sighandler_bug
Before clone getpid() = 1991
sigsender PID = 1993
getpid() mismatch (loop=2710): getpid()=1991; syscall(SYS_getpid)=4823
getpid() mismatch (loop=5383): getpid()=1991; syscall(SYS_getpid)=7504
getpid() mismatch (loop=5383): getpid()=1991; syscall(SYS_getpid)=7504


-- 


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

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

[Bug libc/6910] getpid() wrong in child's signal handler after clone()

[mtk dot manpages at gmail dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael dot kerrisk at gmail
                   |                            |dot com


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

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

[Bug libc/6910] getpid() wrong in child's signal handler after clone()

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2008-09-22 23:56 -------
You cannot use clone this way.  In fact, nobody should use clone.  There are
assumptions made in the system about the way clone is used.  If you want to use
clone you have to do everything yourself, including preparing the thread descriptor.

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


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

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

[Bug libc/6910] getpid() wrong in child's signal handler after clone()

[mtk dot manpages at gmail dot com]

------- Additional Comments From mtk dot manpages at gmail dot com  2008-09-23 01:12 -------
(In reply to comment #2)
> You cannot use clone this way.  In fact, nobody should use clone.  There are
> assumptions made in the system about the way clone is used.  If you want to 
use
> clone you have to do everything yourself, including preparing the thread 
descriptor.

All of this does kind of beg the question: why does glibc provide a clone() 
wrapper then?

-- 


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

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