はncursesでメモリリークを修正できません

Question

settermで2つのスクリーンを設定するncursesプログラムがあります。 私はvalgrindエラー（以下を参照）の束を得るので、私はそれらを正しく仕上げていないと思います。 何が問題なのか？ ありがとうございます！

#include <ncurses.h> 
SCREEN * sstderr; 
SCREEN * sstdout; 
int main() { 
    sstderr = newterm(NULL, stderr, NULL); 
    noecho(); 
    sstdout = newterm(NULL, stdout, stdin); 
    set_term(sstdout); 

    mvaddstr(0, 0, "algo\n"); 
    clrtobot(); 
    getch(); 
    refresh(); 

    set_term(sstdout); 
    endwin(); 
    set_term(sstderr); 
    endwin(); 
    return 0; 
} 

Valgrindのレポート：

==10283== Memcheck, a memory error detector 
==10283== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. 
==10283== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info 
==10283== Command: ./a.out 
==10283== Parent PID: 669 
==10283== 
==10283== 
==10283== HEAP SUMMARY: 
==10283==  in use at exit: 1,225,551 bytes in 313 blocks 
==10283== total heap usage: 328 allocs, 15 frees, 1,242,329 bytes allocated 
==10283== 
==10283== 296 bytes in 1 blocks are possibly lost in loss record 27 of 55 
==10283== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==10283== by 0x4E5B88D: _nc_makenew_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5BB2D: newwin_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5FBC5: _nc_setupscreen_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5B17E: newterm_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x400932: main (in /home/mongo/a.out) 
==10283== 
==10283== 296 bytes in 1 blocks are possibly lost in loss record 28 of 55 
==10283== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==10283== by 0x4E5B88D: _nc_makenew_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5BB2D: newwin_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5FBEA: _nc_setupscreen_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5B17E: newterm_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x400932: main (in /home/mongo/a.out) 
==10283== 
==10283== 296 bytes in 1 blocks are possibly lost in loss record 29 of 55 
==10283== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==10283== by 0x4E5B88D: _nc_makenew_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5BB2D: newwin_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5FD50: _nc_setupscreen_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5B17E: newterm_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x400932: main (in /home/mongo/a.out) 
==10283== 
==10283== 704 bytes in 1 blocks are possibly lost in loss record 37 of 55 
==10283== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==10283== by 0x4E5B8AF: _nc_makenew_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5BB2D: newwin_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5FBC5: _nc_setupscreen_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5B17E: newterm_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x400932: main (in /home/mongo/a.out) 
==10283== 
==10283== 704 bytes in 1 blocks are possibly lost in loss record 38 of 55 
==10283== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==10283== by 0x4E5B8AF: _nc_makenew_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5BB2D: newwin_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5FBEA: _nc_setupscreen_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5B17E: newterm_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x400932: main (in /home/mongo/a.out) 
==10283== 
==10283== 704 bytes in 1 blocks are possibly lost in loss record 39 of 55 
==10283== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==10283== by 0x4E5B8AF: _nc_makenew_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5BB2D: newwin_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5FD50: _nc_setupscreen_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5B17E: newterm_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x400932: main (in /home/mongo/a.out) 
==10283== 
==10283== 197,120 bytes in 44 blocks are possibly lost in loss record 53 of 55 
==10283== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==10283== by 0x4E5BB83: newwin_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5FBC5: _nc_setupscreen_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5B17E: newterm_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x400932: main (in /home/mongo/a.out) 
==10283== 
==10283== 197,120 bytes in 44 blocks are possibly lost in loss record 54 of 55 
==10283== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==10283== by 0x4E5BB83: newwin_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5FBEA: _nc_setupscreen_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5B17E: newterm_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x400932: main (in /home/mongo/a.out) 
==10283== 
==10283== 197,120 bytes in 44 blocks are possibly lost in loss record 55 of 55 
==10283== at 0x4C2CA40: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==10283== by 0x4E5BB83: newwin_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5FD50: _nc_setupscreen_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x4E5B17E: newterm_sp (in /usr/lib/libncursesw.so.6.0) 
==10283== by 0x400932: main (in /home/mongo/a.out) 
==10283== 
==10283== LEAK SUMMARY: 
==10283== definitely lost: 0 bytes in 0 blocks 
==10283== indirectly lost: 0 bytes in 0 blocks 
==10283==  possibly lost: 594,360 bytes in 138 blocks 
==10283== still reachable: 631,191 bytes in 175 blocks 
==10283==   suppressed: 0 bytes in 0 blocks 
==10283== Reachable blocks (those to which a pointer was found) are not shown. 
==10283== To see them, rerun with: --leak-check=full --show-leak-kinds=all 
==10283== 
==10283== For counts of detected and suppressed errors, rerun with: -v 
==10283== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 0 from 0) 

Answer 1

それはFAQです：

おそらく、あなたはメモリリークをチェックするために、このようなdmallocやvalgrindのようなツールを使用していました。それは通常、まだ使用中の多くのメモリを報告します。それは正常です。

ncursesのconfigureスクリプトには、--disable-leaksオプションがあります。このオプションを使用して分析を続行できます。可能であれば、ncursesにメモリを解放するよう指示します。ただし、使用中のメモリのほとんどは「永続的」です。

cursesの実装は、（endwin（）を呼び出した後であっても）次回のrefresh（）の呼び出しで使用できる必要があるため、画面に関連付けられたメモリを解放してはいけません。パフォーマンス上の理由から、メモリチャンクもあります。そのため、cursesアプリケーションのメモリーリークを分析するのは難しくなります。この問題を回避するには、可能なチャンクを解放するncursesライブラリのデバッグバージョンを作成し、_nc_free_and_exit（）関数を使用して終了時に残りの部分を解放します。 ncursesユーティリティとテストプログラムは、たとえばExitProgram（）マクロを使用してこの機能を使用します。

コメントからフォローアップ：ここでの問題は、コンパイル時の設定によっては、ncursesが画面ごとのウィンドウのリスト、または（すべての画面で）ウィンドウのグローバルリストのいずれかを維持することです。後者では、新しい画面を作成するときにリストを破棄していました。 Fixed now：

20170325 
     + fix a memory leak in the window-list when creating multiple screens 
      (reports by Andres Martinelli, Debian #783486).