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
.

Relevant Pages

  • Unix Programming FAQ (v1.37)
    ... Why use _exit rather than exit in the child branch of a fork? ... Why doesn't my process get SIGHUP when its parent dies? ... How do I create a named pipe? ... How do I compare strings using regular expressions? ...
    (comp.unix.programmer)
  • Unix Programming FAQ (v1.37)
    ... Why use _exit rather than exit in the child branch of a fork? ... Why doesn't my process get SIGHUP when its parent dies? ... How do I create a named pipe? ... How do I compare strings using regular expressions? ...
    (comp.unix.programmer)
  • Unix Programming FAQ (v1.37)
    ... Why use _exit rather than exit in the child branch of a fork? ... Why doesn't my process get SIGHUP when its parent dies? ... How do I create a named pipe? ... How do I compare strings using regular expressions? ...
    (comp.unix.programmer)
  • Unix Programming FAQ (v1.37)
    ... Why use _exit rather than exit in the child branch of a fork? ... Why doesn't my process get SIGHUP when its parent dies? ... How do I create a named pipe? ... How do I compare strings using regular expressions? ...
    (comp.unix.programmer)
  • Unix Programming FAQ (v1.37)
    ... Why use _exit rather than exit in the child branch of a fork? ... Why doesn't my process get SIGHUP when its parent dies? ... How do I create a named pipe? ... How do I compare strings using regular expressions? ...
    (comp.unix.programmer)