lkml.org 
[lkml]   [1998]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: fork() memory corruption... is this glibc2 or kernel?
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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.055 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site