On 02/11/2009 07:56 PM, Amos Jeffries wrote: >> On 02/11/2009 06:08 PM, Amos Jeffries wrote: >> >>>> Is there any "definitely lost" record? >>> nly minor stuff which isn't memPool'd >> s it possible that "indirectly lost" is not really lost? >> > No. From the valgrind manual on direct vs indirect leaks: > > "The distinction is that a direct leak is a block which has no pointers to > it. An indirect leak is a block which is only pointed to by other leaked > blocks. Both kinds of leak are bad." > OK. So it looks like we may need to find the direct leak responsible for this indirect leak. Is that information in the valgrind trace?
On a separate note, can you compile Squid with no optimizations and rerun valgrind so that we can see who is calling xmalloc in the indirect trace below? As far as I can tell, DeferredRead and CommRead do not allocate I/O buffers so the malloc call is probably for something else that has a size of approximately 104 bytes. It would be easy to find if all optimizations are disabled. Alternatively, you could run a bunch of sizeof()s in gdb to find a 104-byte class, but the trace would provide more information faster. Thank you, Alex. >>>>> We seem to have tracked the major leak ( ~1MB per request) down to >>>>> these: >>>>> >>>>> mem_obj->delayRead(DeferredRead(DeferReader, this, CommRead(fd, >>>>> buf, len, callback))); >>>>> >>>>> Which generate: >>>>> >>>>> ==21688== 1,251,224 bytes in 12,031 blocks are indirectly lost in loss >>>>> record 26 of 30 >>>>> ==21688== at 0x4C2260E: malloc (vg_replace_malloc.c:207) >>>>> ==21688== by 0x5C4F07: xmalloc (util.c:506) >>>>> ==21688== by 0x574501: DeferredReadManager::delayRead(DeferredRead >>>>> const&) (SquidNew.h:48) >>>>> ==21688== by 0x547596: StoreEntry::delayAwareRead(int, char*, int, >>>>> RefCount<AsyncCall>) (store.cc:241) >>>>> ==21688== by 0x502C4A: HttpStateData::maybeReadVirginBody() >>>>> (http.cc:1332) >>>>> ==21688== by 0x50150D: HttpStateData::processReplyBody() >>>>> (http.cc:1301) >>>>> ==21688== by 0x501177: HttpStateData::readReply(CommIoCbParams >>>>> const&) (http.cc:1107) >>>>> ==21688== by 0x578B7A: JobDialer::dial(AsyncCall&) >>>>> (AsyncJob.cc:215) >>>>> ==21688== by 0x4968D2: AsyncCall::make() (AsyncCall.cc:34) >>>>> ==21688== by 0x495C9F: AsyncCallQueue::fireNext() >>>>> (AsyncCallQueue.cc:53) >>>>> ==21688== by 0x495E57: AsyncCallQueue::fire() >>>>> (AsyncCallQueue.cc:39) >>>>> ==21688== by 0x4DAB1B: EventLoop::runOnce() (EventLoop.cc:131) >>>>> ==21688== by 0x4DABF7: EventLoop::run() (EventLoop.cc:95) >>>>> ==21688== by 0x5216B3: main (main.cc:1346) >>>>> >>>>> >>>>> ==23075== 58,552 bytes in 563 blocks are indirectly lost in loss >>>>> record >>>>> 26 of 30 >>>>> ==23075== at 0x4C2260E: malloc (vg_replace_malloc.c:207) >>>>> ==23075== by 0x5C4F07: xmalloc (util.c:506) >>>>> ==23075== by 0x574501: DeferredReadManager::delayRead(DeferredRead >>>>> const&) (SquidNew.h:48) >>>>> ==23075== by 0x547596: StoreEntry::delayAwareRead(int, char*, int, >>>>> RefCount<AsyncCall>) (store.cc:241) >>>>> ==23075== by 0x502C4A: HttpStateData::maybeReadVirginBody() >>>>> (http.cc:1332) >>>>> ==23075== by 0x50150D: HttpStateData::processReplyBody() >>>>> (http.cc:1301) >>>>> ==23075== by 0x501177: HttpStateData::readReply(CommIoCbParams >>>>> const&) (http.cc:1107) >>>>> ==23075== by 0x578B7A: JobDialer::dial(AsyncCall&) >>>>> (AsyncJob.cc:215) >>>>> ==23075== by 0x4968D2: AsyncCall::make() (AsyncCall.cc:34) >>>>> ==23075== by 0x495C9F: AsyncCallQueue::fireNext() >>>>> (AsyncCallQueue.cc:53) >>>>> ==23075== by 0x495E57: AsyncCallQueue::fire() >>>>> (AsyncCallQueue.cc:39) >>>>> ==23075== by 0x4DAB1B: EventLoop::runOnce() (EventLoop.cc:131) >>>>> ==23075== by 0x4DABF7: EventLoop::run() (EventLoop.cc:95) >>>>> ==23075== by 0x5216B3: main (main.cc:1346) >>>>> >>>>> >>>>> >>>>> I believe its the fact that CommRead is allocating itself a buffer via >>>>> xmalloc(). >>>>> >>>>> Is anyone else able to track this out please? >>>>> >>>>> >>>>> Amos >>>>> >>>>> >>> >> > >
