Re: Valgrind reports possibly lost memory

[Thomas Dickey]

On Mon, May 30, 2022 at 10:22:21AM +0200, TheJackiMonster wrote:
> Hi,
> 
> I'm currently working on a messaging application using ncurses and
> during testing for memory leaks with valgrind I noticed reports from
> ncurses.
> 
> To make sure there's nothing coming from my applications code, I
> created a very short program to test around.
> 
> test.c:
> 
>    #include <stdlib.h>
>    #include <curses.h>
>    
>    int main(int argc, const char** argv)
>    {
>        WINDOW *win;
>        win = initscr();
>        endwin();
>        return 0;

That's an FAQ:

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

The test/demo programs use that information:

https://invisible-island.net/ncurses/ncurses-examples.html
https://github.com/ThomasDickey/ncurses-snapshots/tree/master/test

Without the debugging-library mentioned in the FAQ,
you'd probably see improvement--not 100%--by calling delscreen before exiting.
(To do that, you'd use newterm to get the SCREEN* pointer used as parameter).

>    }
> 
> I've also tested whether initscr() might fail or if the possibly lost
> memory gets reduced using delwin() with the main window before or after
> calling endwin(). It still seems to have those 201 bytes around.
> 
> valgrind --leak-check=full ./test
> 
>    ==13181== Memcheck, a memory error detector
>    ==13181== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et
>    al.
>    ==13181== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright
>    info
>    ==13181== Command: ./test
>    ==13181== 
>    ==13181== 
>    ==13181== HEAP SUMMARY:
>    ==13181==     in use at exit: 786,658 bytes in 279 blocks
>    ==13181==   total heap usage: 290 allocs, 11 frees, 795,386 bytes
>    allocated
>    ==13181== 
>    ==13181== 9 bytes in 1 blocks are possibly lost in loss record 7 of 69
>    ==13181==    at 0x4845888: malloc (in
>    /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>    ==13181==    by 0x49ACD5E: strdup (strdup.c:42)
>    ==13181==    by 0x48DACE6: tparm_setup.lto_priv.0 (lib_tparm.c:659)
>    ==13181==    by 0x48E35B8: _nc_tiparm (lib_tparm.c:1198)
>    ==13181==    by 0x48C29C9: UnknownInlinedFun (lib_mvcur.c:403)
>    ==13181==    by 0x48C29C9: UnknownInlinedFun (lib_mvcur.c:465)
>    ==13181==    by 0x48C29C9: newterm_sp (lib_newterm.c:343)
>    ==13181==    by 0x48C39CE: newterm (lib_newterm.c:367)
>    ==13181==    by 0x48BBC52: initscr (lib_initscr.c:93)
>    ==13181==    by 0x10915C: main (in
>    /mnt/projects/thejackimonster/git/messenger-cli/test)
>    ==13181== 
>    ==13181== 24 bytes in 1 blocks are possibly lost in loss record 26 of
>    69
>    ==13181==    at 0x4845888: malloc (in
>    /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>    ==13181==    by 0x4A1AC76: tsearch (tsearch.c:337)
>    ==13181==    by 0x48DAD01: tparm_setup.lto_priv.0 (lib_tparm.c:660)
>    ==13181==    by 0x48E35B8: _nc_tiparm (lib_tparm.c:1198)
>    ==13181==    by 0x48C29C9: UnknownInlinedFun (lib_mvcur.c:403)
>    ==13181==    by 0x48C29C9: UnknownInlinedFun (lib_mvcur.c:465)
>    ==13181==    by 0x48C29C9: newterm_sp (lib_newterm.c:343)
>    ==13181==    by 0x48C39CE: newterm (lib_newterm.c:367)
>    ==13181==    by 0x48BBC52: initscr (lib_initscr.c:93)
>    ==13181==    by 0x10915C: main (in
>    /mnt/projects/thejackimonster/git/messenger-cli/test)
>    ==13181== 
>    ==13181== 168 bytes in 1 blocks are possibly lost in loss record 49 of
>    69
>    ==13181==    at 0x484AA73: calloc (in
>    /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>    ==13181==    by 0x48DAC5E: tparm_setup.lto_priv.0 (lib_tparm.c:657)
>    ==13181==    by 0x48E35B8: _nc_tiparm (lib_tparm.c:1198)
>    ==13181==    by 0x48C29C9: UnknownInlinedFun (lib_mvcur.c:403)
>    ==13181==    by 0x48C29C9: UnknownInlinedFun (lib_mvcur.c:465)
>    ==13181==    by 0x48C29C9: newterm_sp (lib_newterm.c:343)
>    ==13181==    by 0x48C39CE: newterm (lib_newterm.c:367)
>    ==13181==    by 0x48BBC52: initscr (lib_initscr.c:93)
>    ==13181==    by 0x10915C: main (in
>    /mnt/projects/thejackimonster/git/messenger-cli/test)
>    ==13181== 
>    ==13181== LEAK SUMMARY:
>    ==13181==    definitely lost: 0 bytes in 0 blocks
>    ==13181==    indirectly lost: 0 bytes in 0 blocks
>    ==13181==      possibly lost: 201 bytes in 3 blocks
>    ==13181==    still reachable: 786,457 bytes in 276 blocks
>    ==13181==         suppressed: 0 bytes in 0 blocks
>    ==13181== Reachable blocks (those to which a pointer was found) are not
>    shown.
>    ==13181== To see them, rerun with: --leak-check=full --show-leak-
>    kinds=all
>    ==13181== 
>    ==13181== For lists of detected and suppressed errors, rerun with: -s
>    ==13181== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from
>    0)
> 
> I've attached the full output with the leak kinds. I hope this might
> help. Maybe I'm just missing something but the examples using ncurses
> didn't seem to do anything else to cleanup in the end.
> 
> Surprisingly running vim on my system which should use the same ncurses
> doesn't report any leakage at all.

vim uses the termcap interface (no initscr/endwin).

Last year, there was some discussion about leaks in that,
after which perhaps Bram took my advice to use del_curterm().

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature