Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!nbires!isis!onecom!wldrdg!tony
From: tony@wldrdg.UUCP (Tony Andrews)
Newsgroups: net.lang.c,net.unix
Subject: Re: Microport and SCO Xenix Memory Managment Problems
Message-ID: <105@wldrdg.UUCP>
Date: Mon, 27-Oct-86 13:15:14 EST
Article-I.D.: wldrdg.105
Posted: Mon Oct 27 13:15:14 1986
Date-Received: Tue, 28-Oct-86 23:19:35 EST
References: <646@chinet.UUCP> <4104@ism780c.UUCP>
Organization: Wildridge Consulting,  Boulder, CO
Lines: 23
Xref: mnetor net.lang.c:6221 net.unix:6064

From Tim Smith       sdcrdcf!ism780c!tim
> sbrk has to behave funny because of program that assume a linear
> address space.  Many program that want N bytes do the following:
> 
> 		char * ptr;
> 		ptr = sbrk(0);
> 		brk(ptr+N);
> 
> To make these work correctly, sbrk(0) has to return the start of
> the next segment.

Unfortunately, malloc wasn't fixed to properly deal with the
screwy behavior of brk and sbrk. For small malloc requests,
malloc asks for a 1K chunk and allocates from that. Each time it
decides to grab another 1K it gets it from a NEW segment. The
net effect is that malloc squanders segments and can run out
of memory because of a lack of LDT entries before it even comes
close to hitting other limits.

Tony Andrews
...!ihnp4!onecom!wldrdg!tony
Wildridge Consulting, Inc.
Boulder, CO