> On 02/11/2009 06:08 PM, Amos Jeffries wrote: >>> Is there any "definitely lost" record? >>> >> Only minor stuff which isn't memPool'd >> > Is 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." Amos > > Thank you, > > Alex. > >>> Amos Jeffries wrote: >>> >>>> 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 >>>> >> >> > >
