Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!mtgzx.att.com!jis
From: jis@mtgzx.att.com (J Mukerji)
Newsgroups: comp.soft-sys.andrew
Subject: Re: Help and its memory usage behavior
Message-ID: <0a1Z=ja753w7E0eogH@gazelle.att.com>
Date: 20 Mar 90 15:57:35 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 57

In my original message on this subject I had made the observation that
"enormous amounts of memory seem to be getting allocated and it seems
very little of it is getting freed for reuse. In short there seems to be
a very large memory leak somewhere in Help". I had based this on a set
of experiments that showed that after all the dynamic objects needed for
displaying a particular type of help document had been loaded, an
inexplicably large amount of memory is getting allocated for each
document that is displayed. In that example presented in that message
the following documents were displayed in the order in which they appear
in this list:
[An Andrew ToolKit view (a spreadsheet) was included here, but could not
be displayed.]So in the process of displaying these few documents help
grew by 1.5M from its startup size of ~1.4M. This was on a Sun 4/60
(Sparcstation 1) running Sun OS 4.0.3c, Andrew and X11 compiled using
Sun's C compiler. The workstation has 12M SIMMS and 16M swap space, and
is diskless. The server is a Sun 4/330.

Charles Hayden looked a little further into it and discovered the
following (excerpt from his message to me):

Excerpts from mail: 16-Mar-90 Re: Help and its memory usa.. C C
Hayden@mtgzx.att.com (1411+0)

> I monitored the mallocs with gdb.  I found that it rereads all the
> directories in the help search path every time, and does not properly
> deallocate them.  This is actually two bugs: reinitializing every time,
> which chews up time, and not properly freeint the space.  In my case,
> there were 11 directories of 8K each, accounting for 88K on each query.

> In addition, if you select an item from the "programs" menu or type it
> in, it rereads it.  If you select it from the history, I don't think it
> does.  It is reading into buffers, which it does not free until it
> quits.  So each time you select the same things from "programs", you get
> another copy.  The space will consist of at least the file size, plus
> overhead for the gap, the style sheets and formatting information, etc. 
> Some of these data structures are allocated in fairly large chunks.

> Your measurements seem to indicate that there are some significant data
> structures allocated by the roff processing, that are not being
> deallocated.  I did not measure this.


I would like to bring this to the attention of ITC and seek their help
in fixing this problem in Help. Help is a very popular program here, but
unfortunately if the users do not quit out of it often they keep running
out of swap space. I would like to know if this problem is peculiar to
the Sparc platform or is this a general problem. In either case what
would be the quickest way to start getting it fixed?

Thank you

                            Jishnu Mukerji,  
                           jis@mtgzx.att.com, 
                           +1 201 957 5986,  
                        AT&T Bell Laboratories, 
                      MT 3K-423, 200 Laurel Ave., 
                           Middletown NJ 07748