[Top][All Lists]

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

Re: memory leak - tgetent - ncurses 5.6

From: Steve Litt
Subject: Re: memory leak - tgetent - ncurses 5.6
Date: Wed, 8 Apr 2009 07:32:00 -0400
User-agent: KMail/1.9.9

On Wednesday 08 April 2009 07:19:52 am Thomas Dickey wrote:
> On Tue, 7 Apr 2009, Maciek Borzecki wrote:
> > Hi,
> >
> > I'm writing a small application that's using libedit, which internally
> > calls ncurses.
> > Monitoring it with valgrind, I keep observing the memory leaks coming
> > from tgetent as follows (see attachment for full log):
> I should add this to the faq (it's in the INSTALL file in ncurses
> sources):
>      --disable-leaks
>          For testing, compile-in code that frees memory that normally would
> not be freed, to simplify analysis of memory-leaks.
>          Any implementation of curses must not free the memory associated
> with a screen, since (even after calling endwin()), it must be available
> for use in the next call to refresh().  There are also chunks of memory
> held for performance reasons.  That makes it hard to analyze curses
> applications for memory leaks.  To work around this, build a debugging
> version of the ncurses library which frees those chunks which it can, and
> provides the _nc_free_and_exit() function to free the remainder on exit. 
> The ncurses utility and test programs use this feature, e.g., via the
> ExitProgram() macro.

Boy I sure wish this were a runtime option instead of compiled-in option. I 
haven't read the code, but if for production the programmer didn't use 
_nc_free_and_exit(), and if whatever else --compile provides was if'ed out 
unless a special configuration option was used, one could flip back and forth 
between test and production, and one wouldn't have to recompile the ncurses 
provided with a Linux distribution.



Steve Litt
Recession Relief Package

reply via email to

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