lkml.org 
[lkml]   [1998]   [Jun]   [21]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: fork() memory corruption... is this glibc2 or kernel?
DateSun, 21 Jun 1998 08:00:53 +0200 (MET DST)
From(Rogier Wolff)
tbittih@pal.xgw.fi wrote:
> 
> While coding some network apps I noticed that fork() seemed to corrupt
> memory... so I ripped 95% of the program out and changed some things so
> that the bug hit the "critical" memory area around 10x more frequently...
> I'd want to know whether this can be seen with libc's other than
> 2.0.7pre1/2.0.7pre3... and arch's other than x86...
> ... and after that I'd want to get rid of this bug for good ;)

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. 

Reproduced on 2.0.33, libc5 something. 

					Roger. 

-- 
Actor asks a collegue: "To what do you owe your success in acting?"
Answer: "Honesty. Once you've learned how to fake that, you've got it made."
-------- Custom Linux device drivers for sale! Call for a quote. ----------
Email: R.E.Wolff@BitWizard.nl || Tel: +31-15-2137555 || FAX: +31-15-2138217
-
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 12:43    [from the cache]
©2003-2008