Suspected memory leak in ncurses 5.3

[Reuben Thomas]

I'm using ncurses 5.3 as supplied with Fedora Core 1/x86 (RPM version
5.3-9).

The following program (foo.c):

#include <ncurses.h>

int main(void)
{
        SCREEN *s = newterm(NULL, stdout, stdin);
        set_term(s);

        endwin();
        delscreen(s);

        return 0;
}

causes a memory leak. Tell me now if I'm just doing something stupid, but
I can't see any other "free" routine I should be running other than endwin
and delscreen. Here is the trace produced by:

valgrind --num-callers=8 --leak-check=yes --show-reachable=yes ./foo

[keep reading below!]

==19621== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==19621== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==19621== Using valgrind-2.0.0, a program supervision framework for x86-linux.
==19621== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==19621== Estimated CPU clock rate is 695 MHz
==19621== For more details, rerun with: -v
==19621==
==19621==
==19621== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==19621== malloc/free: in use at exit: 2934 bytes in 5 blocks.
==19621== malloc/free: 190 allocs, 185 frees, 82905 bytes allocated.
==19621== For counts of detected errors, rerun with: -v
==19621== searching for pointers to 5 not-freed blocks.
==19621== checked 4655952 bytes.
==19621==
==19621== 18 bytes in 1 blocks are still reachable in loss record 1 of 5
==19621==    at 0x87868E: malloc (vg_replace_malloc.c:153)
==19621==    by 0x820197: _nc_doalloc (doalloc.c:55)
==19621==    by 0x822C04: _nc_tparm_analyze (lib_tparm.c:374)
==19621==    by 0x822E81: tparam_internal (lib_tparm.c:503)
==19621==    by 0x822C51: tparm (lib_tparm.c:789)
==19621==    by 0x80D180: _nc_mvcur_init (lib_mvcur.c:364)
==19621==    by 0x80EF87: newterm (lib_newterm.c:191)
==19621==    by 0x80485A9: main (in /home/rrt/play/foo)
==19621==
==19621==
==19621== 22 bytes in 1 blocks are still reachable in loss record 2 of 5
==19621==    at 0x87868E: malloc (vg_replace_malloc.c:153)
==19621==    by 0x820365: _nc_home_terminfo (home_terminfo.c:56)
==19621==    by 0x8272DE: _nc_read_entry (read_entry.c:494)
==19621==    by 0x8217DD: grab_entry (lib_setup.c:255)
==19621==    by 0x821B46: setupterm (lib_setup.c:436)
==19621==    by 0x80ED0C: newterm (lib_newterm.c:115)
==19621==    by 0x80485A9: main (in /home/rrt/play/foo)
==19621==    by 0x126BAE: __libc_start_main (in /lib/libc-2.3.2.so)
==19621==
==19621==
==19621== 28 bytes in 1 blocks are definitely lost in loss record 3 of 5
==19621==    at 0x878B00: calloc (vg_replace_malloc.c:284)
==19621==    by 0x826952: read_termtype (read_entry.c:208)
==19621==    by 0x827075: _nc_read_file_entry (read_entry.c:394)
==19621==    by 0x82711B: _nc_read_tic_entry (read_entry.c:415)
==19621==    by 0x82719F: _nc_read_terminfo_dirs (read_entry.c:440)
==19621==    by 0x82732E: _nc_read_entry (read_entry.c:502)
==19621==    by 0x8217DD: grab_entry (lib_setup.c:255)
==19621==    by 0x821B46: setupterm (lib_setup.c:436)
==19621==
==19621==
==19621== 66 bytes in 1 blocks are still reachable in loss record 4 of 5
==19621==    at 0x878C02: realloc (vg_replace_malloc.c:310)
==19621==    by 0x82015F: _nc_doalloc (doalloc.c:50)
==19621==    by 0x823B7F: tparam_internal (lib_tparm.c:155)
==19621==    by 0x822C51: tparm (lib_tparm.c:789)
==19621==    by 0x80D180: _nc_mvcur_init (lib_mvcur.c:364)
==19621==    by 0x80EF87: newterm (lib_newterm.c:191)
==19621==    by 0x80485A9: main (in /home/rrt/play/foo)
==19621==    by 0x126BAE: __libc_start_main (in /lib/libc-2.3.2.so)
==19621==
==19621==
==19621== 2800 bytes in 1 blocks are definitely lost in loss record 5 of 5
==19621==    at 0x87868E: malloc (vg_replace_malloc.c:153)
==19621==    by 0x8273EF: _nc_set_buffer (setbuf.c:115)
==19621==    by 0x8115D1: _nc_setupscreen (lib_set_term.c:219)
==19621==    by 0x80EDF5: newterm (lib_newterm.c:146)
==19621==    by 0x80485A9: main (in /home/rrt/play/foo)
==19621==    by 0x126BAE: __libc_start_main (in /lib/libc-2.3.2.so)
==19621==    by 0x80484F4: (within /home/rrt/play/foo)
==19621==
==19621== LEAK SUMMARY:
==19621==    definitely lost: 2828 bytes in 2 blocks.
==19621==    possibly lost:   0 bytes in 0 blocks.
==19621==    still reachable: 106 bytes in 3 blocks.
==19621==         suppressed: 0 bytes in 0 blocks.
==19621==

All the memory in question seems to have been allocated by newterm, and I
thought that should all have been freed by delscreen.

I have a similar problem with wprintf: it also seems to allocate memory
that is still active when my program exits. I can provide traces for that
too if you're interested.

I read your usual bug reporting guidelines, but since this wasn't a
display error, they didn't seem to apply; I hope that what I've provided
is useful. Please tell me if you want anything else (e.g. a report against
the latest development version).

-- 
http://www.mupsych.org/~rrt/
C++, n.  an octopus made by nailing extra legs onto a dog (Anon)