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, 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

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