parent process behaviour to signal after vfork() - Kernel

This is a discussion on parent process behaviour to signal after vfork() - Kernel ; Hi, Please find the below test code... #include #include #include #include int x = 0; typedef void (*sighandler_t)(int); void fun() { printf("SIGNAL CAUGHT\n"); } int main() { int pid; signal(SIGINT, (sighandler_t)fun); signal(SIGSEGV, (sighandler_t)fun); pid = vfork(); if ( pid == ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: parent process behaviour to signal after vfork()

  1. parent process behaviour to signal after vfork()

    Hi,

    Please find the below test code...

    #include
    #include
    #include
    #include
    int x = 0;
    typedef void (*sighandler_t)(int);
    void fun()
    {
    printf("SIGNAL CAUGHT\n");
    }

    int main()
    {
    int pid;

    signal(SIGINT, (sighandler_t)fun);
    signal(SIGSEGV, (sighandler_t)fun);
    pid = vfork();

    if ( pid == 0 ) {
    printf(" I am child - %d \n", pid);
    x++;
    raise(SIGINT);
    printf("x = %d\n", x);
    exit(0);
    }
    else {
    printf(" I am parent - %d\n", pid);
    raise(SIGSEGV);
    printf("x = %d\n", x);
    }
    }

    Why the parent process is not able to handle/respond the signals, when a child
    once handles the signal, child is created using vfork().

    In vfork() man page -
    "Signals to the parent arrive after the child releases the parent's
    memory."

    How to make sure that child has released the parent memory..??

    Thanks,
    Halesh










    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: parent process behaviour to signal after vfork()


    Hi,

    Check this test


    #include
    #include
    #include
    #include
    int x = 0;
    typedef void (*sighandler_t)(int);
    void fun()
    {
    printf("SIGNAL CAUGHT\n");
    }

    int main()
    {
    int pid;
    char *s = "HELLO";

    signal(SIGINT, (sighandler_t)fun);
    signal(SIGSEGV, (sighandler_t)fun);
    pid = vfork();

    if ( pid == 0 ) {
    printf(" I am child - %d \n", getpid());
    x++;
    //kill(getpid(), SIGINT);
    raise(SIGINT);
    printf("x = %d\n", x);
    exit(0);
    }
    else {
    sleep(2);
    printf(" I am parent - %d\n", getpid());
    raise(SIGSEGV);
    //kill(getpid(), SIGSEGV);
    printf("x = %d\n", x);
    }
    }


    Just little analysis

    If I use kill() to send the signal,it works fine, but not with raise().

    O/p with raise()
    I am child - 15014
    SIGNAL CAUGHT
    x = 1
    I am parent - 15014 (** Child pid o/p in parent getpid)
    x = 1


    O/p with kill()
    I am child - 15016
    SIGNAL CAUGHT
    x = 1
    I am parent - 15015
    SIGNAL CAUGHT
    x = 1


    checked that getpid() function is not working fine when used after raise().
    It is still getting its child's pid in parent.

    Is it a expected behaviour...Please let me know.

    Thanks,
    Halesh

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: parent process behaviour to signal after vfork()

    On Tue, Oct 28, 2008 at 1:43 AM, Halesh S wrote:
    > Hi,
    >
    > Please find the below test code...
    >
    > #include
    > #include
    > #include
    > #include
    > int x = 0;
    > typedef void (*sighandler_t)(int);
    > void fun()
    > {
    > printf("SIGNAL CAUGHT\n");
    > }
    >
    > int main()
    > {
    > int pid;
    >
    > signal(SIGINT, (sighandler_t)fun);
    > signal(SIGSEGV, (sighandler_t)fun);
    > pid = vfork();
    >
    > if ( pid == 0 ) {
    > printf(" I am child - %d \n", pid);
    > x++;
    > raise(SIGINT);
    > printf("x = %d\n", x);
    > exit(0);
    > }
    > else {
    > printf(" I am parent - %d\n", pid);
    > raise(SIGSEGV);
    > printf("x = %d\n", x);
    > }
    > }
    >
    > Why the parent process is not able to handle/respond the signals, when a child
    > once handles the signal, child is created using vfork().
    >
    > In vfork() man page -
    > "Signals to the parent arrive after the child releases the parent's
    > memory."
    >
    > How to make sure that child has released the parent memory..??


    That happens when the child does execve(2) or _exit(2). The man-page could be a little clearer on that point (it implies it, but not very clearly). For man-pages-3.12, I've made the change below.

    Cheers,

    Michael

    diff --git a/man2/vfork.2 b/man2/vfork.2
    index 55044ad..8a7ed50 100644
    --- a/man2/vfork.2
    +++ b/man2/vfork.2
    @@ -94,7 +94,10 @@ but may call
    .PP
    Signal handlers are inherited, but not shared.
    Signals to the parent
    -arrive after the child releases the parent's memory.
    +arrive after the child releases the parent's memory (i.e., after the child calls
    +.BR _exit (2)
    +or
    +.BR execve (2)).
    .SS "Historic Description"
    Under Linux,
    .BR fork (2)

    --
    Michael Kerrisk Linux man-pages maintainer;
    http://www.kernel.org/doc/man-pages/ Found a documentation bug?
    http://www.kernel.org/doc/man-pages/reporting_bugs.html

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: parent process behaviour to signal after vfork()

    On Wed, 29 Oct 2008 08:17:36 CDT, Michael Kerrisk said:

    > diff --git a/man2/vfork.2 b/man2/vfork.2
    > index 55044ad..8a7ed50 100644
    > --- a/man2/vfork.2
    > +++ b/man2/vfork.2
    > @@ -94,7 +94,10 @@ but may call
    > .PP
    > Signal handlers are inherited, but not shared.
    > Signals to the parent
    > -arrive after the child releases the parent's memory.
    > +arrive after the child releases the parent's memory (i.e., after the child calls
    > +.BR _exit (2)
    > +or
    > +.BR execve (2)).


    OK, I'll bite - when is the parent's memory released if the child doesn't
    depart by calling _exit() or execve(), but manages to get killed by an
    unhandled signal or the OOM killer or similar?

    (That's the generic problem with adding itemized lists to an explanation - it's
    rarely clear if the list is an exhaustive list, or a non-complete list of
    examples. Note how often we have flame wars regarding which EQUUX should be
    returned in a corner case that hinge on whether Posix says "Only FOO, BAR,
    and BAZ can be returned" or "FOO, BAR, BAZ are among the errors that can be
    returned")


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFJCUhWcC3lWbTT17ARAqtxAJ0WxsrZVlfEMhof44MX6B yLRBJATQCeJoTR
    L36H9yMajqUjd8HfnPbOEPw=
    =dGAN
    -----END PGP SIGNATURE-----


  5. Re: parent process behaviour to signal after vfork()

    Oops -- forgot the patch. Here it is:

    --- a/man2/vfork.2
    +++ b/man2/vfork.2
    @@ -80,13 +80,15 @@ where a child will be created which then
    immediately issues an
    .BR vfork ()
    differs from
    .BR fork (2)
    -in that the parent is suspended until the child makes a call to
    -.BR execve (2)
    -or
    -.BR _exit (2).
    -The child shares all memory with its parent, including the stack, until
    -.BR execve (2)
    -is issued by the child.
    +in that the parent is suspended until the child terminates
    +(either normally,
    +by calling
    +.BR exit (2),
    +or abnormally, after delivery of a fatal signal),
    +or it makes a call to
    +.BR execve (2).
    +Until that point, the child shares all memory with its parent,
    +including the stack.
    The child must not return from the current function or call
    .BR exit (3),
    but may call
    @@ -95,9 +97,8 @@ but may call
    Signal handlers are inherited, but not shared.
    Signals to the parent
    arrive after the child releases the parent's memory
    -(i.e., after the child calls
    -.BR _exit (2)
    -or
    +(i.e., after the child terminates
    +or calls
    .BR execve (2)).
    .SS "Historic Description"
    Under Linux,
    @@ -135,11 +136,9 @@ The requirements put on
    by the standards are weaker than those put on
    .BR fork (2),
    so an implementation where the two are synonymous is compliant.
    -In particular, the programmer cannot
    -rely on the parent remaining blocked until a call of
    -.BR execve (2)
    -or
    -.BR _exit (2)
    +In particular, the programmer cannot rely on the parent
    +remaining blocked until the child either terminates or calls
    +.BR execve (2),
    and cannot rely on any specific behavior with respect to shared memory.
    .\" In AIXv3.1 vfork is equivalent to fork.
    .SH NOTES
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: parent process behaviour to signal after vfork()

    Hi Valdis,

    On Thu, Oct 30, 2008 at 12:38 AM, wrote:
    > On Wed, 29 Oct 2008 08:17:36 CDT, Michael Kerrisk said:
    >
    >> diff --git a/man2/vfork.2 b/man2/vfork.2
    >> index 55044ad..8a7ed50 100644
    >> --- a/man2/vfork.2
    >> +++ b/man2/vfork.2
    >> @@ -94,7 +94,10 @@ but may call
    >> .PP
    >> Signal handlers are inherited, but not shared.
    >> Signals to the parent
    >> -arrive after the child releases the parent's memory.
    >> +arrive after the child releases the parent's memory (i.e., after the child calls
    >> +.BR _exit (2)
    >> +or
    >> +.BR execve (2)).

    >
    > OK, I'll bite - when is the parent's memory released if the child doesn't
    > depart by calling _exit() or execve(), but manages to get killed by an
    > unhandled signal or the OOM killer or similar?


    Yes, thanks for catching that. The wording really should say, until
    the child does execve(2) or it terminates.

    > (That's the generic problem with adding itemized lists to an explanation - it's
    > rarely clear if the list is an exhaustive list, or a non-complete list of
    > examples. Note how often we have flame wars regarding which EQUUX should be
    > returned in a corner case that hinge on whether Posix says "Only FOO, BAR,
    > and BAZ can be returned" or "FOO, BAR, BAZ are among the errors that can be
    > returned")


    I agree that this is sometime true, but examples need to be looked at
    on a case-by-case basis. Sometimes using deliberately vague language
    is appropriate. But sometimes, the solution is just better, more
    precise language, and I think that's the case here. For
    man-pages-3.13, I applied the patch below.

    Cheers,

    Michael
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread