Re: storage_sink_open is leaky

[Ben Pfaff]

John Darrington <address@hidden> writes:

> I see your point, but I can't totally agree.  There may be cases where
> our test examples  result in the memory being "still reachable", but a
> more complex example it would be "definitely lost". 
> For example, if a particular command forgets to clean up, then a test
> script which calls that command just once, will give a "still
> reachable", but if that command was called many times in a complex
> script, it'd be a definite leak.

This is true.  However, I didn't design the code to free
everything at exit time, so (as you've already seen) it's going
to take a lot of work to make it "--show-reachable" clean.

>      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.
>
> Hmm.  I can't produce this problem.  Did you compile/configure with any
> non-default  options ??

No.  I'll investigate myself then.
-- 
Ben Pfaff 
email: address@hidden
web: http://benpfaff.org