Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!cwjcc!kiwi!chet
From: chet@kiwi.CWRU.EDU (Chet Ramey)
Newsgroups: gnu.bash.bug
Subject: Re: memory leak, also trouble with echo (bash 0.99)
Summary: memory leak possible fix
Message-ID: <367@cwjcc.CWRU.Edu>
Date: 16 Jun 89 20:27:58 GMT
References: <8906160229.AA05556@cit-vlsi>
Sender: news@cwjcc.CWRU.Edu
Reply-To: chet@cwjcc.INS.CWRU.Edu (Chet Ramey)
Distribution: gnu
Organization: CWRU Andrew R. Jennings Computing Center
Lines: 25

In article <8906160229.AA05556@cit-vlsi> andy@cit-vlsi.ai.mit.edu (Andy Fyfe) writes:
>[running on a sun3, sunos 3.5]
>The routine init_terminal_io calls "xmalloc" but never "free".  It gets
>called, it seems, with every (or at least many) SIGWINCH, and in no time
>you can have a *VERY* large data segment.  Included is a patch changing
>the xmalloc to alloca.  (Then again, maybe it would be best to just
>allocate a fixed buffer?)

[ He gives a fix that changes the call to xmalloc to a call to alloca ]

Looking at the code, I don't see why the xmalloc is required at all.  A
couple of lines before the xmalloc takes place, buffer is intialized to
point at term_string_buffer, which is a static buffer of 2048 chars.  I
took the call to xmalloc out of my version and don't seem to have suffered
any ill effects. 

Chet




Chet Ramey     Network Services Group, CWRU    chet@cwjcc.INS.CWRU.Edu

"The flagon with the dragon has the potion with the poison;
	the vessel with the pestle holds the brew that is true!"