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” (normally not freed).

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 exit_curses() function to free the remainder on exit. The ncurses utility and test programs use this feature, e.g., via the ExitProgram() macro.

getent leak

It is only avoidable when recompiling from source ncurses library with the no-leaks --disable-leaks option, and only using it in a debugging environment.

https://invisible-island.net/ncurses/ncurses.faq.html#config_leaks

https://manpages.ubuntu.com/manpages/jammy/man3/memleaks.3ncurses.html