Re: Chunked allocator evaluation

"Chemolli Francesco (USI)" wrote:

> > Also, imo it would help alot if we could parse stack from xmalloc(),
> > create a list of caller funcs, say upto 4 pointers deep, and count
> > them as a single entity, perhaps even see on cachemgr. This would
> > make it easy finding most often used mallocers. But thats
> > not trivial.
>
> leaky, from the Mozilla project, does exactly this.

A similar function (stack frame parsing) is also built into glibc.

However, so far I have found memprof highly usable in finding memory leaks, and
think that malloc debuggers are generally doing a better job in these tasks
than anything we could dream up in Squid. Because of this I have as goal that
both mempools and cbdata should be malloc debugger compatible on request.

However, having rudimentary malloc debugging within Squid is very good for
field diagnostics. But from practical reasons I think such detailed memory
debugging should be limited to certain allocation classes.

With the increased usage of memory pools in Squid, there should be less reasons
for malloc traces. As we in most cases know quite well where memory for a given
memory pool is alloceted the question is more of why/when isn't it freed than
where is it allocated.

--
Henrik