lkml.org 
[lkml]   [1998]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: fork() memory corruption... is this glibc2 or kernel?
Date
From
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 13:43    [W:0.130 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site