RE: Chunked allocator evaluation

> > All leaky does is write to a file all allocation/deallocation
> > operations in an highly compact form. A program then takes the
> > binary image to find out symbols and decodes that file, looking
> > for unfreed mallocs and printing their stacks in understandable
> > form, and getting rudimentary statistics.
>
> iow a grown up version of our --enable-xmalloc-debug-trace. Not quite
> what Adrian was asking for, but yet somewhat useful given the proper
> analyzis tool. However, such trace files tends to be rather
> huge even if
> written in compact form given the malloc pattern of Squid. Also, given
> that there are quite good stand-alone malloc debuggers which does this
> and a lot more I don't really see the need of integrating such a thing
> into Squid.
>
> We have quite many malloc debugging features in Squid as it
> is, but the
> quality of the debugging code has much to ask (if it at all works).
> I think most of it should be ripped out, or maybe in some
> cases polished
> up to be more useable in field testing. For testing in a lab, malloc
> debuggers do a much better job.

Well, some printf-bombs Robert and I had to use qualify, and not for
the "compact format" class :) (think of a cache.log
which is 1.2Gb, and you get the picture).
This said, I agree with you. One proper tool is better than 3 half-assed
attempts :)
This said, I don't think I'm qualified enough to write said proper tool.

In unrelated news, I'm beginning to mumble about dirty CPP tricks which
would
allow to specify a maximum compiled-in debug level, saving CPU
clicks by not performing many debug level comparisions.
Do you think such an hack would be useful?

-- 
	/kinkie