Messages in this thread | | | Date | Sun, 21 Jun 1998 11:36:24 +0300 (EET DST) | From | Tuomas Heino <> | Subject | Re: 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
| |