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.018 / U:29.772 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site