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

> 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

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