Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.questions
Subject: Re: sbrk(2) question
Message-ID: <1991Mar15.105340.14597@thunder.mcrcim.mcgill.edu>
Date: 15 Mar 91 10:53:40 GMT
References: <1991Mar8.180132.12025@Think.COM> <4296@skye.ed.ac.uk> <2045@necisa.ho.necisa.oz.au>
Organization: McGill Research Centre for Intelligent Machines
Lines: 39

In article <2045@necisa.ho.necisa.oz.au>, boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes:
> 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:

[edited -dM]
>>        sbrk(100000);
>>        printf("hello world\n");
>>        sbrk(-100000);
>>        printf("hello again\n");

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

You are correct, of course, but on SunOS 4.1 it's even worse than this.

Apparently Sun decided that nobody wants to use sbrk and malloc in the
same program.  malloc and sbrk are incompatble.  Even when all
arguments to sbrk are positive multiples of the page size, you *still*
get a core dump when you mix sbrk() and malloc()!  I don't know what
possessed them to introduce this bug; I guess it's just another
instance of Sun deciding they didn't care about compatibility with the
rest of the world.

I don't know why they even bothered to provide sbrk(), because nearly
everything winds up using some library routine or other which
eventually calls malloc().

(If I sound annoyed, it's because I am.  I spent days trying to track
down that core dump....)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu