[Top][All Lists]

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

Re: storage_sink_open is leaky

From: Ben Pfaff
Subject: Re: storage_sink_open is leaky
Date: Mon, 24 Jan 2005 10:03:10 -0800
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)

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

reply via email to

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