Re: Major memory leak in DeferredRead

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 11 Feb 2009 22:33:46 -0700

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
>>>>>
>>>>>
>>>
>>
>
>
Received on Thu Feb 12 2009 - 05:34:06 MST

This archive was generated by hypermail 2.2.0 : Fri Feb 13 2009 - 12:00:03 MST