Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!munnari.oz.au!metro!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz.au (Boyd Roberts)
Newsgroups: comp.unix.questions
Subject: Re: sbrk(2) question
Message-ID: <2045@necisa.ho.necisa.oz.au>
Date: 15 Mar 91 01:14:25 GMT
References: <1991Mar8.180132.12025@Think.COM> <4296@skye.ed.ac.uk> <6582@auspex.auspex.com> <4312@skye.ed.ac.uk>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 31

In article <4312@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes:
|While experimenting, I was reminded of another hazard of sbrk().  For
|example, this program produces a segmentation fault on a Sun4 under
|SunOS 4.1:
|
|    #include <stdio.h>
|    
|    extern char *sbrk();
|    
|    main()
|    {
|        sbrk(100000);
|        printf("hello world\n");
|        sbrk(-100000);
|        printf("hello again\n");
|        exit(0);
|    }

Well, I thought everybody new that sbrk(2) and malloc(3) just
don't mix.  Odds on printf(3) calls malloc and gets some memory
whose address is > sbrk(0) + 100000*.  The second printf references
this memory after the second sbrk and it's length violation city!

malloc(3) and sbrk(2) -- be careful out there.


Boyd Roberts			boyd@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''

* Obviously rounded up to the next page.