Re: Major memory leak in DeferredRead

> 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
>>>>
>>
>>
>
>
Received on Thu Feb 12 2009 - 02:56:41 MST