Well the array of pointers are in fact reused by just resetting the child
count to zero. The problem was that the objects allocated and stored in the
array was not deallocated in the process. The problem is not visible until
you reuse the ElementStack though.
/ Erik
-----Original Message-----
From: Adams, David [mailto:[EMAIL PROTECTED]]
Sent: den 12 juni 2001 17:05
To: '[EMAIL PROTECTED]'
Subject: RE: Naughty memory leak in nightly build 2001-06-11
I had a very similar problem with V1.4 (4-26-2001 build) that I posted a few
days ago with no response. I ran BOUNDS CHECKER which was catching the
memory leaks in the ElemStack::addChild() method at line 317 where it
allocates 'QName' for the new child. This happened while parsing a
'well-formed' but 'not-valid' XML/DTD document.
// Add this id to the end of the row's child id array and bump the count
curRow->fChildren[curRow->fChildCount++] = new QName(child);
What I found was that the the array entry already had an allocated item in
it, which seemed funny to me because the code looks as if it expects the
array to always be growng and not reused. I had a similar code fix. I may
be wrong here, but it looks as if Erik's 'fChildren' was suppose to be empty
also, but isn't. I noticed no code changes for 'ElemStack.cpp' in the V1.5
6-8-2001 nightly build.
> -----Original Message-----
> From: Erik Rydgren [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, June 12, 2001 9:49 AM
> To: [EMAIL PROTECTED]
> Subject: Naughty memory leak in nightly build 2001-06-11
>
> Hi!
>
> I downloaded the latest nightly build, 1.5 candidate and compiled it into
> our project which always reuse the validator. I then got MASSIVE memory
> leaking out. I tracked the problem down to the ElemStack::addLevel()
> method.
> It reuses the allocated QName* array (fChildren) without deallocating the
> old children but just zeroing the counter. I added code to cleanup the
> mess
> a bit and the memory leak went away.
>
> Regards
> Erik Rydgren
> Mandarinen systems AB
> Sweden
>
> PS: I have found more memory leaks and fixed them in this release. I will
> post the fixes shortly.
>
> --------------------------------------------------------------------------
> --
> -----
> Fixed code
> --------------------------------------------------------------------------
> --
> -----
>
> unsigned int ElemStack::addLevel()
> {
> // See if we need to expand the stack
> if (fStackTop == fStackCapacity)
> expandStack();
>
> // If this element has not been initialized yet, then initialize it
> if (!fStack[fStackTop])
> {
> fStack[fStackTop] = new StackElem;
> fStack[fStackTop]->fChildCapacity = 0;
> fStack[fStackTop]->fChildren = 0;
> fStack[fStackTop]->fMapCapacity = 0;
> fStack[fStackTop]->fMap = 0;
> }
> >> START OF ADDED CODE TO FIX PROBLEM
> else {
> // Cleanup the old element before reuse
> for (unsigned int childIndex = 0; childIndex <
> fStack[fStackTop]->fChildCount; ++childIndex)
> delete fStack[fStackTop]->fChildren[childIndex];
> }
> >> END OF ADDED CODE TO FIX PROBLEM
>
> // Set up the new top row
> fStack[fStackTop]->fThisElement = 0;
> fStack[fStackTop]->fReaderNum = 0xFFFFFFFF;
> fStack[fStackTop]->fChildCount = 0;
> fStack[fStackTop]->fMapCount = 0;
> fStack[fStackTop]->fValidationFlag = false;
> fStack[fStackTop]->fCurrentScope = Grammar::TOP_LEVEL_SCOPE;
> fStack[fStackTop]->fCurrentGrammar = 0;
>
> // Bump the top of stack
> fStackTop++;
>
> return fStackTop-1;
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
