NCurses 内存分配 valgrind 消息

Question

我最近一直在自学 NCurses，我决定在 valgrind 中测试我的代码以检查是否有任何内存泄漏。这少量代码给出了与我的程序相同的错误结果，我想知道是否有人知道它有什么问题或者可以指导我找到答案。

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

==20986== Memcheck，内存错误检测器
==20986== 版权所有 (C) 2002-2013，GNU GPL'd，Julian Seward 等人
==20986== 使用 Valgrind-3.10.1 和 LibVEX；使用 -h 重新运行以获得版权信息
==20986== 命令：./a.out
==20986==
==20986==
==20986== 堆摘要：
==20986== 在退出时使用：193 个块中的 281,089 字节
==20986== 堆总使用量：248 次分配，55 次释放，353,425 字节分配
==20986==
==20986== 泄漏摘要：
==20986== 绝对丢失：0 个块中的 0 个字节
==20986== 间接丢失：0 个块中的 0 个字节
==20986== 可能丢失：0 个块中的 0 个字节
==20986== 仍然可以访问：193 个块中的 281,089 字节
==20986== 抑制：0 个块中的 0 个字节
==20986== 重新运行 --leak-check=full 以查看泄漏内存的详细信息
==20986==
==20986== 对于检测到的和抑制的错误的计数，重新运行：-v
==20986== 错误摘要：0 个上下文中的 0 个错误（抑制：0 个中的 0 个）

谢谢你的时间。

Answer 1

显示的代码没有任何问题。各种运行时库在运行时为其内部缓冲区分配内存是正常的，而不会在共享库卸载时释放它们。

Answer 2

图书馆经常在您的 int main() 结束后做一些事情。

话虽这么说，但之后发生的事情的示例如下：

#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 ()

在示例程序中。以上输出由 GDB 提供。但是，相关性在堆栈跟踪行 #7 上，您会看到 listp=0x7ffff76355f8; 的部分。这是注册到 atexit(); 函数的函数回调列表。可能在 ncurses 中使用的任何东西，甚至一些 std/stl 库都可以在那里进行清理。一般来说，或者至少正如我所读到的那样，valgrind 不能总是获取那些免费的资源，因为调用库正在管理它们的清理。

Answer 3

答案在 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 提供了可能对测试内存泄漏有用的软件包：libncurses5-dbg and libncursesw5-dbg。

NCurses 内存分配 valgrind 消息

NCurses memory allocation valgrind message

c++

memory

memory-leaks

ncurses