Re: setupterm memory leak

[Usamah Malik]

Looks like a call to set_curterm(null) will return the cur_term ptr while  
keeping the pre-condition.

?


On Mon, 11 May 2009 22:43:31 -0000, Usamah Malik <address@hidden>  
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.
>
> 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:
> >
> > > 587c587,589
> > > <       set_curterm(termp);
> > > ---
> > > >      TERMINAL *oldterm = set_curterm(termp);
> > > >     del_curterm(oldterm);
> > >
> > > ------------------
> > >
> > >
> > > Specifically:
> > >
> > > Current chunk:
> > >
> > > <       set_curterm(termp);
> > >
> > > Suggested Fix:
> > >
> > > >      TERMINAL *oldterm = set_curterm(termp);
> > > >     del_curterm(oldterm);
> > > -----------------
> > >
> > > 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.
> >
> > > Thx!
> > >
> > >
> > >
> > > 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
> > > > > 587,589c587
> > > > > <       TERMINAL *oldterm = set_curterm(termp);
> > > > > <
> > > > > <       del_curterm(oldterm);
> > > >  this chunk doesn't appear in ncurses...
> > > >
> > > > > ---
> > > > > >      set_curterm(termp);
> > > >  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/