Re: [PATCH v3 2/2] read-cache: plug a few leaks

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

 



On Sat, Jun 8, 2013 at 10:56 AM, René Scharfe
<rene.scharfe@xxxxxxxxxxxxxx> wrote:
> Am 08.06.2013 16:04, schrieb Felipe Contreras:
>
>> On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe
>> <rene.scharfe@xxxxxxxxxxxxxx> wrote:
>>>
>>> Am 08.06.2013 14:15, schrieb Felipe Contreras:
>>
>>
>>>> Why leave it out? If somebody makes the mistake of doing the above
>>>> sequence, would you prefer that we leak?
>>>
>>>
>>> Leaking is better than silently cleaning up after a buggy caller because
>>> it
>>> still allows the underlying bug to be found.
>>
>>
>> No, it doesn't. The pointer is replaced and forever lost. How is
>> leaking memory helping anyone to find the bug?
>
> Valgrind can tell you where leaked memory was allocated, but not if you free
> it in the "wrong" place.

It is the correct place to free it. And nobody will ever find it with
valgrind, just like nobody has ever tracked down the hundreds of leaks
in Git that happen reliably 100% of the time, much less the ones that
happen rarely.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]