Re: storage_sink_open is leaky

[Ben Pfaff]

Ben Pfaff <address@hidden> writes:

> John Darrington <address@hidden> writes:
>
>> I've been slowly plugging the memory leaks that valgrind is reporting
>> (currently down to 81622 bytes over all the tests).
>
> Are you sure that all of these are bona fide leaks, and not just
> stuff that we don't free because it's pointed to by a global
> variable, etc.?  I don't recall ever seeing valgrind report that
> many leaks in the past, and I noticed that at least one of your
> changes (regarding t_trns in vfm.c) should only affect the
> "global variable still references at exit" case.

Okay, I updated to the latest CVS and with
        make check SUPERVISOR='valgrind --leak-check=yes'
I only see one leak:
        ==3402== 36 bytes in 1 blocks are definitely lost in loss record 2 of 4
        ==3402==    at 0x1B904EDD: malloc (vg_replace_malloc.c:131)
        ==3402==    by 0x8073DC6: xmalloc (alloc.c:39)
        ==3402==    by 0x80888FB: dfm_open_writer (dfm-write.c:52)
        ==3402==    by 0x80B3C98: internal_cmd_print (print.c:190)
        ==3402==    by 0x80B3AD1: cmd_print (print.c:114)
        ==3402==    by 0x807A706: cmd_parse (command.c:207)
        ==3402==    by 0x80A2ECB: execute_command (main.c:134)
        ==3402==    by 0x80A2E7C: parse_script (main.c:104)
        ==3402==    by 0x80A2E18: main (main.c:91)
This one is simple, so I have checked in a fix.

Are you using --show-reachable=yes on the valgrind command line?
Those are not really leaks, because that data is still reachable
at program exit, and so I don't think they are really worth
"fixing".

By the way, every test I run reports this error:
        ==3122== Invalid free() / delete / delete[]
        ==3122==    at 0x1B905460: free (vg_replace_malloc.c:153)
        ==3122==    by 0x80696DB: done_settings (set.q:1059)
        ==3122==    by 0x809B609: done_glob (glob.c:190)
        ==3122==    by 0x808B540: err_hcf (error.c:231)
        ==3122==    by 0x80A2EF9: execute_command (main.c:129)
        ==3122==    by 0x80A2E7C: parse_script (main.c:104)
        ==3122==    by 0x80A2E18: main (main.c:91)
        ==3122==  Address 0x52BFEDD4 is on thread 1's stack
I think this must be something you introduced in the latest
check-in.
-- 
Positronic Functional Android Fabricated for Fighting