Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!fluke!ssc-vax!voodoo!zombie
From: zombie@voodoo.UUCP (Mike York)
Newsgroups: comp.sys.sgi
Subject: Re: The memory eater strikes back (2nd attempt to get attention)
Message-ID: <605@voodoo.UUCP>
Date: 25 Oct 89 17:01:17 GMT
References: <8910210901.aa24434@SMOKE.BRL.MIL> <89Oct21.211825edt.3287@neat.cs.toronto.edu>
Reply-To: zombie@voodoo.UUCP (Mike York)
Organization: Voodoo Graphics Project
Lines: 29

In article <89Oct21.211825edt.3287@neat.cs.toronto.edu> moraes@CS.TORONTO.EDU (Mark Moraes) writes:
>Nope. Even if you remove all libraries except for -lmalloc, it still
>grows. You can see the problem over only a couple of iterations by
>printing the value of sbrk(0) after every loop. The break will grow
>steadily when using -lmalloc or amalloc/afree from -lmpc. With libc
>malloc, the BSD4.3 malloc or any other working malloc, the value stays
>constant after the first iteration.
>
>>b) Is it a bug?
>>   - known?
>>   - fixed when?
>
>Looks like a bug. Not fixed in Irix 3.2, it seems.

Actually, it seems that it IS fixed in 3.2:

I'm running it right now on a 4D/70GT with 8MB and Irix 3.2 -- no
problems.  After the first iteration, the value of sbrk(0) remained
constant.  On a 4D/70G with 8MB running Irix 3.1, the value of sbrk
does indeed grow, and after 60 iterations, it REALLY slows down.
However, by inserting mallopt(M_MXFAST, 0) in mem.c before the main
loop, the program works as desired under 3.1.


-- 
Mike York
Boeing Computer Services, Renton, Washington
(206) 234-7724
uw-beaver!ssc-vax!voodoo!zombie