> > 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