Messages in this thread | | | Date | Sun, 21 Jun 1998 08:21:19 +0200 (MET DST) | From | MOLNAR Ingo <> | Subject | Re: fork() memory corruption... is this glibc2 or kernel? |
| |
On Sun, 21 Jun 1998, Rogier Wolff wrote:
> When I read teh "readme" I realized what was going on. > > FILE * descriptors have a buffer associated with them . So, if you > fork () that buffer gets copied. > > If I run ./simple, it will work just fine, as the stdout > filedescriptor is flushed on every carriage return. If I do "./simple > > bla", there are lots of duplicates, as the stdout buffer gets > copied into many sub-processes which eventually write out the > buffer before exiting.
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.
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |