Valgrind reports possibly lost memory

[TheJackiMonster]

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;
   }

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.

Best regards
Jacki

full-output.txt
Description: Text document

signature.asc
Description: This is a digitally signed message part