Re: fork() memory corruption... is this glibc2 or kernel?

Tuomas Heino (tbittih@xgw.fi)
Mon, 22 Jun 1998 00:21:10 +0300 (EET DST)


On Sun, 21 Jun 1998, Roderich Schupp wrote:

> Note that after a fork(), two handles exist where one existed
> before. The application must assure that, if both handles will ever be
> accessed, that they will both be in a state where the other could
> become the active handle first. The application must prepare for a
> fork() exactly as if it were a change of active handle. (If the only
> action performed by one of the processes is one of the exec functions
> or _exit() (not exit()), the handle is never accessed in that
> process.)
[snip]
now is there a way to do most of the exit() stuff easily and skip things
that break things up? ;)
>
> That is, glibc is correct and the bug is in your program. And
> issuing a fflush() before the fork() is the correct fix.
>
Nope makes absolutely no diff... the stream which's file position is
getting corrupted is an INPUT stream, not output; therefore fflush()
won't have any effect on it...
child's exit() seems to be messing parent's _input_ stream position...
now this test program can avoid the bug by using _exit() instead of exit()...
... but as the network db mirror thingie I'm writing might be using
atexit and alike without me even knowing about that I reallly can't just
exit the children with "fflush(NULL); _exit(code);" ... Well I'll reread
all the (missing?) documentation I can find on this thing ...

Hmm how offtopic is this for linux-kernel? (... _if_ there isn't anything
wrong with the kernel that is...)

-_-
the children are supposed to
dup2(child[id].out[1]), STDOUT_FILENO); where out is from a pipe()
created by the parent... how to do that safely if the related things are
full of boobytraps? (the code seems to work but...)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu