NCurses memory allocation valgrind message

Question

I've been teaching myself NCurses lately and I decided to test my code in valgrind to check for any memory leaks. This small amount of code gives the same error result as my program and I would like to know if someone knows what is wrong with it or can direct me to the answer.

#include <ncurses.h>
int main()
{
    initscr();
    WINDOW *win = newwin(0,0,10,10);
    delwin(win);
    endwin();
    return 0;
}

==20986== Memcheck, a memory error detector
==20986== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==20986== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==20986== Command: ./a.out
==20986==
==20986==
==20986== HEAP SUMMARY:
==20986== in use at exit: 281,089 bytes in 193 blocks
==20986== total heap usage: 248 allocs, 55 frees, 353,425 bytes allocated
==20986==
==20986== LEAK SUMMARY:
==20986== definitely lost: 0 bytes in 0 blocks
==20986== indirectly lost: 0 bytes in 0 blocks
==20986== possibly lost: 0 bytes in 0 blocks
==20986== still reachable: 281,089 bytes in 193 blocks
==20986== suppressed: 0 bytes in 0 blocks
==20986== Rerun with --leak-check=full to see details of leaked memory
==20986==
==20986== For counts of detected and suppressed errors, rerun with: -v
==20986== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Thanks for your time.

Answer 1

Libraries often times do things after your int main() has ended.

That being said, an example of what happens after is below:

#7  0x00007ffff72abfe8 in __run_exit_handlers (status=0, 
  listp=0x7ffff76355f8 <__exit_funcs>, 
  run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#8  0x00007ffff72ac035 in __GI_exit (status=<optimized out>) at exit.c:104
#9  0x00007ffff7292837 in __libc_start_main (
  main=0x429e26 <main(int, char**)>, argc=1, argv=0x7fffffffde28, 
  init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
  stack_end=0x7fffffffde18) at ../csu/libc-start.c:325
#10 0x0000000000419f69 in _start ()

in an example program. The above output was provided by GDB. However, the relevance is on stacktrace line #7, you see a part that says listp=0x7ffff76355f8; that is a list of function callbacks registered to the atexit(); function. Likely anything used in ncurses, and even some of the std/stl libraries can have cleanups in there. Generally, or at least as I've read, valgrind can't always pick up on those resource free's because the calling library is managing their cleanup.

Answer 2

There's nothing wrong with the shown code. It is normal for various runtime libraries to allocate memory for their internal buffers at runtime, without deallocating them when the shared library gets unloaded.

Answer 3

The answer is in the ncurses FAQ Testing for Memory Leaks:

Perhaps you used a tool such as dmalloc or valgrind to check for memory leaks. It will normally report a lot of memory still in use. That is normal.

The ncurses configure script has an option, --disable-leaks, which you can use to continue the analysis. It tells ncurses to free memory if possible. However, most of the in-use memory is "permanent".

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.

Debian, for instance, provides packages which might be useful for testing memory leaks: libncurses5-dbg and libncursesw5-dbg.