Re: Major memory leak in DeferredRead

Alex Rousskov wrote:
> 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.

Okay. Might be this bit then,it at least mentions direct loss:

==21688==
==21688== 1,286,064 (34,840 direct, 1,251,224 indirect) bytes in 257
blocks are definitely lost in loss record 27 of 30
==21688== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==21688== by 0x5C4F07: xmalloc (util.c:506)
==21688== by 0x4B0A60: ConnStateData::readSomeData() (SquidNew.h:48)
==21688== by 0x4B2BF8:
ConnStateData::clientReadRequest(CommIoCbParams const&)
(client_side.cc:2602)
==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)
==21688==

>
>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>
>>
>

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13
   Current Beta Squid 3.1.0.5