[Top][All Lists]

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

Re: setupterm memory leak

From: Thomas Dickey
Subject: Re: setupterm memory leak
Date: Mon, 11 May 2009 18:57:00 -0400 (EDT)

On Mon, 11 May 2009, Usamah Malik wrote:

OK I see the point: The caller owns (and is responsible for) the memory allocated. The fix may need to goto tecla in this case.

However, I don't see any way to get a pointer to cur_term from a calling application. Did I miss something here? Do we need to add a get_curterm() function to the API to make this possible.

cur_term is a pointer, and is declared in term.h

In the ongoing work to provide a reentrant interface, cur_term is a #define for a function that returns the real value (so it cannot be
reassigned by user code).  It might have been more consistent with
regard to set_curterm and del_curterm to add a get_curterm, but there
were a dozen or so global variables that I dealt with in the same way.

I noticed a "reuse" flag in _nc_setupterm that may have been an incomplete attempt at fixing this problem.

I appreciate your help with this. Thx!

On Mon, 11 May 2009 22:23:19 -0000, Thomas Dickey <address@hidden> wrote:

On Mon, 11 May 2009, Usamah Malik wrote:

<       set_curterm(termp);
    TERMINAL *oldterm = set_curterm(termp);



Current chunk:

<       set_curterm(termp);

Suggested Fix:

    TERMINAL *oldterm = set_curterm(termp);

Sorry... the diff was reversed. Does it make sense now?

Well... I did read through the tecla source, and saw it calls setupterm,
doesn't seem to free memory.

But unless setupterm is in some way smart enough to detect that its file descriptor refers to the same file (not simple), then repeated calls on it could very well be for different devices that are used concurrently.

I think it's better to document how to free resources used in setupterm (which is obscure in the manpage). Something along the lines of

        Each call to setupterm allocates a TERMINAL structure, and points
        cur_term to the newly created structure as a side-effect.  You can
        save values of cur_term after each call to setupterm and
        manipulate them with set_curterm and del_curterm.


On Sat, 09 May 2009 23:19:36 -0000, Thomas Dickey <address@hidden> wrote:

On Thu, May 07, 2009 at 09:08:42PM -0000, Usamah Malik wrote:
We'd been finding memory leaks (via valgrind) in ncurses. This happens
when ncurses is being used from tecla library. The stack is below:
==5125== 46,254 (2,236 direct, 44,018 indirect) bytes in 13 blocks are
definitely lost in loss record 43 of 45
==5125==    at 0x400497E: calloc (vg_replace_malloc.c:397)
==5125==    by 0x5386C86: _nc_setupterm (in /usr/lib/libncurses.so.5.7)
==5125==    by 0x53871E2: setupterm (in /usr/lib/libncurses.so.5.7)
==5125==    by 0x825596E: _gl_change_terminal (in .........)
ncurse version: 5.7
platform: linux x86
On deeper analysis of setupterm we found a global variable being assigned
chunks of memory at every setupterm call. Applying the following diff to
lib_setup.c seems to fix it:
diff ./ncurses/tinfo/lib_setup_old.c ./ncurses/tinfo/lib_setup.c
<       TERMINAL *oldterm = set_curterm(termp);
<       del_curterm(oldterm);
this chunk doesn't appear in ncurses...

this chunk does...
(but your diff suggests that the first chunk is in ncurses, and that
you want to use the second)

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Thomas E. Dickey

reply via email to

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