Bug 74346 - tgetent leaks memory on every call.
Summary: tgetent leaks memory on every call.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libtermcap
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Petr Raszyk
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-09-20 22:13 UTC by Michael Kohne
Modified: 2015-01-08 00:00 UTC (History)
2 users (show)

Fixed In Version: libtermcap-2.0.8 Release 44
Clone Of:
Environment:
Last Closed: 2006-01-03 11:24:13 UTC
Embargoed:


Attachments (Terms of Use)
patch for memory leak (758 bytes, patch)
2003-05-16 23:23 UTC, Lev Iserovich
no flags Details | Diff
fixes all tgetent leaks (758 bytes, patch)
2003-05-18 04:59 UTC, Lev Iserovich
no flags Details | Diff
again (973 bytes, patch)
2003-05-18 05:03 UTC, Lev Iserovich
no flags Details | Diff
libtermcap-2.0.8-44.src.rpm (223.16 KB, application/x-rpm)
2006-01-03 09:25 UTC, Petr Raszyk
no flags Details

Description Michael Kohne 2002-09-20 22:13:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0)

Description of problem:
Repeated calls to the tgetent routine from within a single process seem to leak 
memory. Demonstration program 'ft.C' to be compiled with 
g++ -o ft ft.C -ltermcap
(NOTE: assumes vt100 is defined in your system's termcap database).
#include <stdlib.h>
#include <termcap.h>
#include <assert.h>

int main(int argc, char **argv)
{
  for(;;)
    int ret = tgetent(NULL,"vt100");
}

The program that was initially affected by this problem is a port of some very 
old, strange software, and it does wierd terminal handling. This forces me to 
call tgetent repeatedly. As a workaround, I'm caching the output of 
tgetstr/tgetnum/etc for the capabilities I'm interested in.


Version-Release number of selected component (if applicable):
libtermcap-2.0.8-28
libtermcap-devel-2.0.8-28


How reproducible:
Always

Steps to Reproduce:
1. run 'top'
2. On a seperate console, run the 'ft' program (see description)
3. Watch top
	

Actual Results:  The 'ft' process will steadily increase in size until it eats 
all memory in the system, and then crash.

Expected Results:  The 'ft' process should NOT increase in size. The only thing 
it should do is eat up CPU. 

Additional info:

Possibly relevant RPM versions:
libtermcap-2.0.8-28
libtermcap-devel-2.0.8-28
gcc-c++-2.96-98
gcc-2.96-98
glibc-devel-2.2.4-13
glibc-2.2.4-13

Comment 1 Lev Iserovich 2003-05-16 23:23:02 UTC
Created attachment 91752 [details]
patch for memory leak

This patch will fix the memory leak on tgetent.
This problem also caused bash to die when you would set the TERM variable to an
invalid type, then valid, then invalid again. 
This was because a security patch to termcap.c made it allocate a new buffer on
every call, regardless of whether a buffer was passed in.
This patch fixes that by remembering correctly when libtermcap allocates memory
and only freeing it in those cases (eliminates the bash crash),
and always freeing the buffer when the reference is updated (eliminating the
memory leak).

Comment 2 Lev Iserovich 2003-05-16 23:40:35 UTC
The previous patch fixes only part of the memory leak it seems..
bash now works correctly, however the ft program from Michael's report still
eats memory.
It seems to be the linked list handling in tgetent..


Comment 3 Lev Iserovich 2003-05-18 04:59:23 UTC
Created attachment 91764 [details]
fixes all tgetent leaks

This includes the above patch, and also fixes the leak in the "ft" program
Michael describes.
tgetent is now leak-free!
(used valgrind - http://developer.kde.org/~sewardj/ - to find this one -- cool
tool!)

Comment 4 Lev Iserovich 2003-05-18 05:03:51 UTC
Created attachment 91765 [details]
again

again -- messed up my filenames, and last one didn't take. sorry.

Comment 5 Petr Raszyk 2006-01-03 09:25:15 UTC
Created attachment 122706 [details]
libtermcap-2.0.8-44.src.rpm


Thank you for your precise example !
I can not use your patch today (the issue
above was partially resolved), but 
there is still the 'bug' (as you describe) !

Thanks !

---------------------------------------------
--- termcap-2.0.8/termcap.c.rasold	2006-01-02 17:10:29.000000000 +0100
+++ termcap-2.0.8/termcap.c	2006-01-02 17:10:52.000000000 +0100
@@ -421,6 +421,7 @@
	sp = get_one_entry(fp, term_list[index]);
	if (sp == NULL) break;
	build_list(&l, sp, term_list);
+	free (sp);
   }
   fclose(fp);
---------------------------------------------


Note You need to log in before you can comment on or make changes to this bug.