Re: [gtk-list] Re: memory leak GtkText

[Shevek <shevek plaice valhalla net>]

AFAIK this happens on clist in testgtk.c as well, I had that using up 25Mb
of space.

On 7 May 1998, Teemu Kalvas wrote:

> Jason Nordwick <nordwick@scam.XCF.Berkeley.EDU> writes:
> 
> > > > Teemu Kalvas, on  5/7/1998, wrote the following:
> > > > > 
> > > > > I tested this with a shorter program which just repeatedly puts random
> > > > > lines into the text widget and then takes them away, and it seems that
> > > > > the memory use of the program rises every time text is added but never
> > > > > goes down when text is removed.  So I conclude that there must be a
> > > > > memory problem with GtkText.
> > > > > 
> > 
> > I just ran it through for awhile and never saw the problem.
> > There were 50 inserts and deletes done between each of these intervals
> > (done by add/delete x 50, not grouped).
> > 
> >  7113 nordwick   2   0   428K  1368K select   0:00  0.00%  0.00% gtk-test
> >  7113 nordwick   2   0   428K  1368K select   0:00  0.00%  0.00% gtk-test
> >  7113 nordwick   2   0   428K  1340K select   0:00  0.00%  0.00% gtk-test
> >  7113 nordwick   2   0   428K  1324K select   0:00  0.00%  0.00% gtk-test
> > 
> > However when I group adds, then do one delete at the end I get this:
> > 
> >  7113 nordwick   2   0   444K  1352K select   0:00  0.00%  0.00% gtk-test
> > 
> > I think this is just because the realloc of the ->text buffer needs to
> > go get more memory of page alignment... no bug deal, because free
> > wont return it to the OS, just keep it for later use.  I can then
> > go up to a buffer of over 10k before the segment grows by another 16k.
> 
> When doing this experiment repeatedly I get something like this:
> 
> Start:
> chery     3160  1.6  1.9  2552  1548  p0 S    12:55   0:00 gtk-test
> Add up to 10k:
> chery     3160  1.0  1.9  2588  1580  p0 S    12:55   0:00 gtk-test
> Delete:
> chery     3160  0.8  1.9  2588  1580  p0 S    12:55   0:00 gtk-test
> Add:
> chery     3160  0.7  1.9  2588  1584  p0 S    12:55   0:00 gtk-test
> Delete:
> chery     3160  0.7  1.9  2588  1584  p0 S    12:55   0:00 gtk-test
> Add:
> chery     3160  0.6  1.9  2592  1592  p0 S    12:55   0:00 gtk-test
> Delete:
> chery     3160  0.5  1.9  2592  1592  p0 S    12:55   0:00 gtk-test
> Add:
> chery     3160  0.5  2.0  2592  1596  p0 S    12:55   0:00 gtk-test
> Delete:
> chery     3160  0.5  2.0  2592  1596  p0 S    12:55   0:00 gtk-test
> Add:
> chery     3160  0.5  2.0  2612  1612  p0 S    12:55   0:01 gtk-test
> Delete:
> chery     3160  0.5  2.0  2612  1612  p0 S    12:55   0:01 gtk-test
> 
> The memory used after the add/remove 10k chararters -cycle does not
> always go up, so it seems that the behaviour is data dependent -- it
> might have something to do with the line start cache maybe, as the
> actual line lengths used are randomised in that test program.
> 
> With the original program the memory amounts lost were a bit more
> severe, it lost about 30M into hyperspace before I noticed something
> was going wrong.  I estimate that by that time it had done about
> 10000-20000 cycles like this.
> 
> And no, I do not use timeouts or an idle function in this program.
> 
> -- 
> Teemu Kalvas
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 

--
S.
GM/CS/MU -d+ H+>++ s+: !g p2 au0 !a w+++ v-(---) C++++$ UL++++$ UB+
US++ UI+++$ P+>++++ L++++$ 3+ E--- N+ K !W(-----) M+(-) !V -po+ Y+ t+
5++ !j !R G' !tv b+++ D++ B--- e+ u+* h++ f? r-- n---- y?