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
