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. > 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. -Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part