Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PROBLEM: getpid() returning same value as getppid()

77 views
Skip to first unread message

Sébastien Paumier

unread,
May 26, 2010, 11:10:03 AM5/26/10
to
Hi,
here is a bug that occurs on my kernel 2.6.31-21, maybe with older ones.
If a C program contains a function with the constructor attribute that
calls getpid(), then, a call to syscall(SYS_fork) produces a son that
obtains the same value calling getpid() or getppid().

Best regards,
Sébastien Paumier

test.c

Nick Bowler

unread,
May 26, 2010, 11:20:02 AM5/26/10
to
On 16:45 Wed 26 May , S�bastien Paumier wrote:
> Hi,
> here is a bug that occurs on my kernel 2.6.31-21, maybe with older ones.
> If a C program contains a function with the constructor attribute that
> calls getpid(), then, a call to syscall(SYS_fork) produces a son that
> obtains the same value calling getpid() or getppid().

The GNU C library caches the results of getpid, which is probably the
cause of your grief. This cache relies on the glibc wrappers for fork
and friends, which you have bypassed by using syscall directly.

--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Michal Hocko

unread,
Jun 2, 2010, 11:10:02 AM6/2/10
to
On Wed 26-05-10 11:16:51, Nick Bowler wrote:

> On 16:45 Wed 26 May , S?bastien Paumier wrote:
> > Hi,
> > here is a bug that occurs on my kernel 2.6.31-21, maybe with older ones.
> > If a C program contains a function with the constructor attribute that
> > calls getpid(), then, a call to syscall(SYS_fork) produces a son that
> > obtains the same value calling getpid() or getppid().
>
> The GNU C library caches the results of getpid, which is probably the
> cause of your grief. This cache relies on the glibc wrappers for fork
> and friends, which you have bypassed by using syscall directly.

man page for getpid states that explicitly:
NOTES
Since glibc version 2.3.4, the glibc wrapper function for
getpid() caches PIDs, so as to avoid additional system calls when
a process calls getpid() repeatedly. Normally this caching is
invisible, but its correct operation relies on support in the
wrapper functions for fork(2), vfork(2), and clone(2):
if an application bypasses the glibc wrappers for these system
calls by using syscall(2), then a call to getpid() in the child
will return the wrong value (to be precise: it will return the
PID of the parent process). See also clone(2) for discussion
of a case where getpid() may return the wrong value even when
invoking clone(2) via the glibc wrapper function.

>
> --
> Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--
Michal Hocko
L3 team
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic

0 new messages