mån 2009-02-16 klockan 14:27 +0100 skrev Steinar H. Gunderson:
> I've reported dumps of these several times already. I'm not entirely sure
> what more information you need.
Not sure either.
What I do know however is that valgrind traces in general gets very
unreliable unless Squid is built with valgrind support. This due to some
of the memory allocation magics Squid is performing resulting in
valgrind not really knowing what is inuse or not or from where memory
really was allocated. The --with-valgrind-debug option not only enables
valgrind instrumentation to the code, it also switches cbdata and memory
pools to a malloc tracer friendly mode of operation.
I also know from experience that shutdown traces often is quite
misleading as well, mostly due to the shutdown cleanup in Squid not
cleaning everything up properly (not really needed as the os frees it
all on exit, so nobody cares much), often resulting in false leak
indications in such traces.
I have found runtime valgrind reports triggered by mgr:mem to be very
accurate however.
Also you mentioned CBDataCall growing a lot.. that's from
--enable-debug-cbdata, not related to valgrind. Not sure anyone has
verified that code ever in Squid-3, or if it even provides any
meaningful data. Adds another cachemgr screen with detailed cbdata info.
Regards
Henrik
Received on Mon Feb 16 2009 - 18:45:56 MST
This archive was generated by hypermail 2.2.0 : Tue Feb 17 2009 - 12:00:04 MST