Re: fork() memory corruption... is this glibc2 or kernel?
Tuomas Heino (tbittih@xgw.fi)
Sun, 21 Jun 1998 11:36:24 +0300 (EET DST)
On Sun, 21 Jun 1998, MOLNAR Ingo wrote:
[snip]
>
> (also, you check for erroneous fork()s in a broken way, fork returns -1 on error, not 0.)
>
well I guess you already figured this out but I think I should say it so
the others get it too: that's an oversimplification to exit(-1) the
parent on error and exit(0) the child in right after it has started...
On Sun, 21 Jun 1998, MOLNAR Ingo wrote:
[snip]
>
> i think the bug is a bit more complex. The actual 'corruption' is
> reproducible no matter what the standard output is.
>
> the 'secret' shared space between forked child and parent is the open
> file's offset. If the child does an lseek() on fd, it changes it in the
> parent too. The corruption magically goes away if you change the exit()
> call to _exit(). since the 'main process' uses fgets, it depends on the
> file offset. exit() tries to change the offset under libc6, and
> occasionally messes it up for the parent. Normally one wouldnt notice this
> bug.
>
> so this looks like a libc6 bug. It's not 'memory corruption' actually, but
> 'messed up file offset', which results in random file offsets, and
> sometimes this means the 'BUGBUG' part of the file.
>
or libc* ? as in if stdout is a file then the the _first_ fork()/exit()
pair causes noticeable 'corruption' with both libc5 & libc6...
now... which part of exit() is messing up the offset?
and how 'safe' is it to use fflush(NULL); _exit(0); instead of exit(0); ?
as in 'the real program' (network db mirror app) uses pipe(); fork(); dup2();
to pipe the stdout/stderr of the children to the parent for delayed output...
do pipe()s need fflushing or not?
... now where should we send this message? as in if it's a libc* bug ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu