bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ncurses seems to be leaking memory?


From: Benno Schulenberg
Subject: ncurses seems to be leaking memory?
Date: Thu, 11 Jun 2020 13:32:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

Hi,

While testing a branch of nano with an rc file with lots of
coloring rules, valgrind started reporting invalid reads.

But this was with the ncurses supplied by the distro
(ncurses-6.1-1ubuntu1.1).  I then tried with ncurses-6.2,
patch 20200418, which I had still installed in /usr/local.

With that version there were no more invalid reads, but now
valgrind reported possibly lost blocks.  So I updated to patch
20200606, to see if it had gotten better.  But now there are
even more possibly lost blocks, even when not using any coloring
rules at all.  :|  See below.  Are these just spurious reports?
Does Valgrind fail to understand how ncurses uses its memory?
Or is there something amiss?


==22241== Memcheck, a memory error detector
==22241== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==22241== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==22241== Command: src/nano --ignorercfiles
==22241==
==22241==
==22241== HEAP SUMMARY:
==22241==     in use at exit: 375,868 bytes in 851 blocks
==22241==   total heap usage: 1,102 allocs, 251 frees, 512,280 bytes allocated
==22241==
==22241== 9 bytes in 1 blocks are possibly lost in loss record 21 of 450
==22241==    at 0x4C2FB0F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22241==    by 0x514B9B9: strdup (strdup.c:42)
==22241==    by 0x4E7F93F: tparm_setup (lib_tparm.c:591)
==22241==    by 0x4E82FD7: _nc_tiparm (lib_tparm.c:1077)
==22241==    by 0x4E5FBD7: _nc_mvcur_init_sp (lib_mvcur.c:403)
==22241==    by 0x4E60029: _nc_mvcur_init (lib_mvcur.c:465)
==22241==    by 0x4E604CC: newterm_sp (lib_newterm.c:332)
==22241==    by 0x4E60738: newterm (lib_newterm.c:356)
==22241==    by 0x4E5CABA: initscr (lib_initscr.c:94)
==22241==    by 0x413E9C: main (nano.c:2268)
==22241==
==22241== 24 bytes in 1 blocks are possibly lost in loss record 58 of 450
==22241==    at 0x4C2FB0F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22241==    by 0x51CB483: tsearch (tsearch.c:338)
==22241==    by 0x4E7F95E: tparm_setup (lib_tparm.c:592)
==22241==    by 0x4E82FD7: _nc_tiparm (lib_tparm.c:1077)
==22241==    by 0x4E5FBD7: _nc_mvcur_init_sp (lib_mvcur.c:403)
==22241==    by 0x4E60029: _nc_mvcur_init (lib_mvcur.c:465)
==22241==    by 0x4E604CC: newterm_sp (lib_newterm.c:332)
==22241==    by 0x4E60738: newterm (lib_newterm.c:356)
==22241==    by 0x4E5CABA: initscr (lib_initscr.c:94)
==22241==    by 0x413E9C: main (nano.c:2268)
==22241==
==22241== 168 bytes in 1 blocks are possibly lost in loss record 405 of 450
==22241==    at 0x4C31B25: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22241==    by 0x4E7F852: tparm_setup (lib_tparm.c:589)
==22241==    by 0x4E82FD7: _nc_tiparm (lib_tparm.c:1077)
==22241==    by 0x4E5FBD7: _nc_mvcur_init_sp (lib_mvcur.c:403)
==22241==    by 0x4E60029: _nc_mvcur_init (lib_mvcur.c:465)
==22241==    by 0x4E604CC: newterm_sp (lib_newterm.c:332)
==22241==    by 0x4E60738: newterm (lib_newterm.c:356)
==22241==    by 0x4E5CABA: initscr (lib_initscr.c:94)
==22241==    by 0x413E9C: main (nano.c:2268)
==22241==
==22241== LEAK SUMMARY:
==22241==    definitely lost: 0 bytes in 0 blocks
==22241==    indirectly lost: 0 bytes in 0 blocks
==22241==      possibly lost: 201 bytes in 3 blocks
==22241==    still reachable: 375,667 bytes in 848 blocks
==22241==         suppressed: 0 bytes in 0 blocks
==22241== Reachable blocks (those to which a pointer was found) are not shown.
==22241== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==22241==
==22241== For counts of detected and suppressed errors, rerun with: -v
==22241== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)


When using an rc file with just two coloring rules, I additionally get this:

==32096== 24 bytes in 1 blocks are possibly lost in loss record 64 of 470
==32096==    at 0x4C2FB0F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32096==    by 0x51CB483: tsearch (tsearch.c:338)
==32096==    by 0x4E774A8: _nc_reset_color_pair (new_pair.c:217)
==32096==    by 0x4E58832: _nc_init_pair (lib_color.c:654)
==32096==    by 0x4E58A8B: init_pair_sp (lib_color.c:694)
==32096==    by 0x4E58AAC: init_pair (lib_color.c:701)
==32096==    by 0x4E76FD6: assume_default_colors_sp (lib_dft_fgbg.c:86)
==32096==    by 0x4E77019: use_default_colors_sp (lib_dft_fgbg.c:51)
==32096==    by 0x4E77031: use_default_colors (lib_dft_fgbg.c:58)
==32096==    by 0x405EA9: set_interface_colorpairs (color.c:74)
==32096==    by 0x413EBA: main (nano.c:2276)

Benno

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]