Way cool - Linux

This is a discussion on Way cool - Linux ; I don't know what this little program is doing but it's fun to watch. #include #include #include main() { int fd[2],num; pid_t id; id=num; printf("%i",num); pipe(fd); id=vfork(); if(id==0) { printf("success\n"); printf("%i",num); } close(fd[1]); close(fd[0]); return 0; } I wonder what ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Way cool

  1. Way cool

    I don't know what this little program is doing but it's fun to watch.

    #include
    #include
    #include

    main() {
    int fd[2],num;
    pid_t id;
    id=num;
    printf("%i",num);
    pipe(fd);
    id=vfork();
    if(id==0) {
    printf("success\n");
    printf("%i",num);
    }
    close(fd[1]);
    close(fd[0]);
    return 0;
    }

    I wonder what the numbers that are changing is? The number that doesn't
    change must be the process id.


    Bill



  2. Re: Way cool

    Bill Cunningham wrote:
    > I don't know what this little program is doing but it's fun to watch.
    >
    > #include
    > #include
    > #include
    >
    > main() {
    > int fd[2],num;
    > pid_t id;
    > id=num;
    > printf("%i",num);
    > pipe(fd);
    > id=vfork();
    > if(id==0) {
    > printf("success\n");
    > printf("%i",num);
    > }
    > close(fd[1]);
    > close(fd[0]);
    > return 0;
    > }
    >
    > I wonder what the numbers that are changing is? The number that doesn't
    > change must be the process id.


    What numbers change? The first printf prints an uninitialized local
    variable. On my system (Kubuntu 7.10), this just prints 0, but on other
    systems it may print any other value, and as this doesn't change until
    the next printf, this also prints 0, the fact that it's done in the
    child doesn't matter.
    The pid is nowhere output.

    It segfaults at the end (unless it's run by gdb ;-) This is because the
    child returns first rather than _exit(2)s (from man vfork):
    "The child must not return from the current function or call exit(3),
    but may call _exit(2)."

    Josef
    --
    These are my personal views and not those of Fujitsu Siemens Computers!
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize (T. Pratchett)
    Company Details: http://www.fujitsu-siemens.com/imprint.html

  3. Re: Way cool


    > What numbers change? The first printf prints an uninitialized local
    > variable. On my system (Kubuntu 7.10), this just prints 0, but on other
    > systems it may print any other value, and as this doesn't change until the
    > next printf, this also prints 0, the fact that it's done in the child
    > doesn't matter.
    > The pid is nowhere output.
    >
    > It segfaults at the end (unless it's run by gdb ;-) This is because the
    > child returns first rather than _exit(2)s (from man vfork):
    > "The child must not return from the current function or call exit(3), but
    > may call _exit(2)."
    >
    > Josef


    I get about 7 changing digits the number 1073 which stays the same and
    "transaction "commencing or something like that. Hum I thought it might be
    the same everywhere.

    Bill



  4. Re: Way cool

    Bill Cunningham wrote:
    >> What numbers change? The first printf prints an uninitialized local
    >> variable. On my system (Kubuntu 7.10), this just prints 0, but on other
    >> systems it may print any other value, and as this doesn't change until the
    >> next printf, this also prints 0, the fact that it's done in the child
    >> doesn't matter.
    >> The pid is nowhere output.
    >>
    >> It segfaults at the end (unless it's run by gdb ;-) This is because the
    >> child returns first rather than _exit(2)s (from man vfork):
    >> "The child must not return from the current function or call exit(3), but
    >> may call _exit(2)."
    >>
    >> Josef

    >
    > I get about 7 changing digits the number 1073 which stays the same and
    > "transaction "commencing or something like that. Hum I thought it might be
    > the same everywhere.


    I fail to see from the source code why this should happen.
    All the program does ist vfork() once, after which a parent process and
    a child process exist, both sharing the same address space until the
    child disconnects by *directly* _exit()ing or exec()ing.

    Prior to the vfork(), the parent prints this uninitialized variable
    "num" and after the vfork() the child prints the same uninitialized
    variable.
    Then the child returns (with the parent waiting), destroying the stack,
    and eventually terminates. The parent then wakes up and attempts to
    continue on the already unraveled and maybe partially overwritten(*) stack.

    (*) In the process of terminating by "return"ing, the child process may
    very well call some cleanup functions which will overwrite the stack
    and/or modify some data relevant to the parent. Hence the restriction
    that the child process must not call exit() (which may or may not do
    some cleaning up) but may call _exit() (which just does the syscall).

    The only explanation for your output may be that the child did indeed
    modify some state variables, e.g. the return address of main() by
    calling some nested functions, such that the parent, when it returns,
    happens to end up somewhere undesired.

    In the end it's an example of undefined behaviour of a program doing
    something unspecified (a child return-ing after a vfork()).

    Josef
    --
    These are my personal views and not those of Fujitsu Siemens Computers!
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize (T. Pratchett)
    Company Details: http://www.fujitsu-siemens.com/imprint.html

+ Reply to Thread