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
