Re: [PATCH 3/4] unpack-trees: plug a memory leak

[Felipe Contreras <felipe.contreras@gmail.com>]

On Sun, Jun 2, 2013 at 5:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Sun, Jun 2, 2013 at 2:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> Before overwriting the destination index, first let's discard it's
>>>> contents.
>>>>
>>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>>> ---
>>>>  unpack-trees.c | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/unpack-trees.c b/unpack-trees.c
>>>> index ede4299..eff2944 100644
>>>> --- a/unpack-trees.c
>>>> +++ b/unpack-trees.c
>>>> @@ -1146,8 +1146,10 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
>>>>
>>>>       o->src_index = NULL;
>>>>       ret = check_updates(o) ? (-2) : 0;
>>>> -     if (o->dst_index)
>>>> +     if (o->dst_index) {
>>>> +             discard_index(o->dst_index);
>>>>               *o->dst_index = o->result;
>>>> +     }
>>>
>>> I seem to recall that many callers set src_index and dst_index to
>>> the same istate, and expect that the original istate pointed by the
>>> src_index to remain usable.  Is it safe to discard it like this at
>>> this point?
>>
>> Who expects that?
>
> The patch you posted expects that no such caller depends on
> src_index being left alone by the call, and I was asking if that
> expectantion holds, i.e. if it is safe to discard.

No, it expects that no caller depends on dst_index being left alone.

> I think your answer can be one of "Yes, it is safe, as no current
> caller does so", "I dunno, I did not check", or "No, this and that
> caller need to be adjusted".

If what you say is true, it would not be safe, but AFAIK what you said
is not true, so it is safe. I wouldn't have sent the patch otherwise.

-- 
Felipe Contreras