[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: question about term_names memleak (are this bug really fixed)

From: Thomas Dickey
Subject: Re: question about term_names memleak (are this bug really fixed)
Date: Thu, 30 Oct 2003 16:59:35 -0500 (EST)

On Thu, 30 Oct 2003, Stanislav Ievlev wrote:

> Hello Friends!
> In the latest ncurses (20031004) you have said that bug with memory leak
> in _nc_free_termtype fixed. But valgrind (memory leak checker) still
> tell me:

I fixed _a_ memory leak.  But there's more than one thing to consider.
Some memory is allocated "permanently" (except for the debugging option
"--disable-leaks").  Some code is used by tic in a different manner than
the ordinary library users - so it makes freeing a terminal entry not

> ==29210== 28 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==29210==    at 0x134DBA: calloc (vg_replace_malloc.c:273)
> ==29210==    by 0x804A8F1: read_termtype (read_entry.c:208)
> ==29210==    by 0x804B382: _nc_read_file_entry (read_entry.c:394)
> ==29210==    by 0x804B4B0: _nc_read_terminfo_dirs (read_entry.c:440)

>From inspection, I think this is one of the cases where one slice of
code uses malloc, but the other copies into a static buffer.  Occasionally
I work to reduce these cases.  Usually I focus on the cases shown by
configuring with "--disable-leaks".  But that code makes this particular
instance go away (so I'll have to look closer).

> Test program was simple:
> --
> #include <curses.h>
> #include <term.h>
> main()
> {
>     setupterm((char *)0, 1, (int *)0);
>     if (cur_term) del_curterm(cur_term);
> }
> --
> I compile it in following way:
> $gcc -o test test.c libncurses_g.a
> $valgrind --show-reachable=yes --leak-check=yes -v ./test 2>log
> My question is: why you use so complicated algorithm for freeing of 
> term_names?
> Are memory leak still exist or my program is wrong?

I think you're talking about (mainly) the complication of using a struct
which may be allocated versus a static variable.

> There are also other memory leak:
> ==29210== 24 bytes in 1 blocks are still reachable in loss record 1 of 2
> ==29210==    at 0x134942: malloc (vg_replace_malloc.c:153)
> ==29210==    by 0x804BC60: _nc_home_terminfo (home_terminfo.c:56)
> ==29210==    by 0x804B5CD: _nc_read_entry (read_entry.c:494)
> ==29210==    by 0x80491C9: grab_entry (lib_setup.c:255)

yes - I know about that one.  It's "permanent" - allocated one time during
execution, doesn't grow.  So it's not very interesting.

> P.S. Are any mailing list for generic (not a bugs) curses discussion
> exists? I wrote some ncurses based libraries and want to consult with
> curses guru.

no - this is the only list.  There's little enough traffic that no one's
complained recently (after filtering spam).

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]