Re: squid-3.HEAD IPAddress leak

>
> On Fri, 2008-02-08 at 12:14 +0900, Adrian Chadd wrote:
>>
>> > Together they make a pretty tree. But every used piece is
>> eseentially
>> > another new, memset, free.
>>
>> Ah, and here you will have problems.
>>
>> The members of that struct should probably be malloc, free, and not
>> new/delete. You're using new/delete which -should- map to a default
>> new operator and head off to the malloc libraries, but -squids- idea
>> of the malloc interface could differ from the -library- idea of
>> the malloc interface.
>
> You can tell C++ to use malloc/free if needed. Am I reading right that
> the OS calls free itself ? Usually /either/ clients free and allocate,
> or libraries free and allocate - never a mix. (Because even in C the
> malloc libraries can be partially overridden).
>
> If squid is doing the allocation and free the following:
>
>> So you should probably drop the new/delete'ing of the addrinfo stuff
>> and replace it with malloc/free.
>
> is irrelevant, but if its shared then we should definitely not use C++
> because operator delete can't be called. (And don't use talloc, or
> anything else either.

No it is very carefully non-shared. Handled via new/delete and only by
IPAddress internals.

>
>> You're also memset()'ing the addrinfo struct whether you allocated
>> it or not, which may be double-memset'ing the thing, and if someone
>> passed in an addrinfo it may have structure members which have now
>> been leaked.
>
> tighter boundaries may help this.

Amos
Received on Tue Feb 12 2008 - 17:17:25 MST