In message <Pine.NEB.4.10.9908181940330.17768-100000@pc1.whooppee.com>,
Paul Goyette writes:

>I just ran into this problem, and wondered whether it was working
>correctly or if it's a bug.  The original code is part of the amanda
>backup package, amcheck.c, but what it basically does is:
>
>1. malloc() some memory, store pointer to it in a char *msg
>2. fork process 1, which does some stuff, and overwrite the stuff
>   that *msg points to
>3. fork process 2, which attempts to use contents of *msg
>4. main() then waits for both subprocesses to finish.
>
>What actually happened is that when subprocess 1 overwrites the
>memory block pointed to by *msg, both the main process and the
>subproccess 2 see the new value!
>
>I thought that when you did a fork(), the new process was supposed to
>get its _own_ copy of the original process's address space.  But in this
>situation, it seems that all three processes are sharing the _same_ copy
>of the malloc()d data structure!
>
>Also, this just started happening after I updated from 1.4C to 1.4J
>(-current as of Saturday 8/14/99);  prior to that, everything worked
>just fine!

Yes, that's how fork() (not vfork()) is meant to work.  Sounds like
you discovered a VM bug. If it's that blatant it should be easy for
someone to to fix. But please send a PR so we don't forget.

If you can reduce the bug to a simple reproducible test-case, and send
a PR, we could day-dream about incorporating it into a VM regression-test
suite ...