In article <1992Feb1.194237.8963@athena.mit.edu> ajh@gec-mrc.co.uk writes:
quoted text
>Can somebody explain why this code misbehaves?
>Seems like fork() manages to corrupt the calling process code in some way.

Ok, I thought: somebody has some installation problem, and this isn't a
real bug. But I tried it out anyway: just in case. And lo and behold, it
corrupts the program. So I got a little nervous: this seemed like a
really fundamental bug. Time for some source-checking.

Half an hour later I still hadn't found the kernel bug: I found a
race-condition in the fork(), and corrected that one, but it wasn't very
bad, and the program still crashed. Now I started to panic: it might be
some weird bug in the memory manager - most programs exec right efter
the fork. But no, no bug that I could see. That's when I decided to take
a look at the program...

quoted text
>    int pid, i;
[ deleted ]
quoted text
>           wait(pid);

That's not how wait works (and it would have been checked by gcc if you
had included unistd.h), and this just results in the exit value being
written to an address determined by the pid of the child.  So the fault
was in the program all the time, and people using linux can once more
breathe more easily (but boy did I get worried! :). 

Moral of the story: check your bug-reports as this kind of thing is kind
of silly, BUT I'd rather see these kind of reports than none at all:
this "bug" meant I found a real one that could bite somebody in the
future (it wasn't very probable: the race-codition only happened when
linux was out of memory and started paging, AND several processes tried
to fork at once).

                Linus