Nick,
Yes I think that's the same problem ...
Tinny
Nick Denning wrote:
> Dear People,
>
> I have just joined the mailing list to enquire on a problem I think I have
> with the XERCES-C 1.5 parser which I think has a memory leak. I have
> checked the obvious things, having been a Xerces programmer for over a year
> now. I have now just received this bug report, while in the process of
> trying to send the details of the memory leak that I had located.
> (Unfortunately I first sent it without a subject and then with a large zip
> file attached showing all my boundchecker screen shots that rather exceeded
> the 100k message limit).
>
> I wonder if the person that has reported this problem as fixed could confirm
> that this affects the details in my attachment below.
>
> The problem I had found manifests itself when I am using bounds checker, and
> the attached word document gives the full scenario and details of the pieces
> that are leaking. Bounds checker reports overwriting an array and the
> circumstances pointing to the existance of a problem are pretty compelling.
>
> Incidentally this does not happen for small messages, as I include in the
> zip file (that I cannot currently send) an MS project and example messages
> that will work without leak, as well as messages that give a problem.
> Message 3 gives both the leakage of entries during the build process and the
> leakage of memory at the clean up phase, while the smaller messages 4 and 3
> only give the first leakage, while message 6 goes through cleanly. (Message
> 1 and 2 were my starting point).
>
> If anyone would like the zip file I can send it to them directly.
>
> Nick
>
> Nick Denning
> Strategic Thought Limited
> The Old Town Hall
> 4 Queens Road
> London SW19 8YA
> tel: +44 (0)20 8410 4000
> fax: +44 (0)20 8410 4030
> mob: +44 (0)7710 338072
> website: http://www.strategicthought.co.uk
> <http://www.strategicthought.co.uk>
> ARM website: http://www.arm-risk.com <http://www.arm-risk.com>
>
> //
> ---------------------------------------------------------------------------
> // ElemStack: Stack top access
> //
> ---------------------------------------------------------------------------
> unsigned int ElemStack::addChild(QName* const child, const bool toParent)
> {
> if (!fStackTop)
> ThrowXML(EmptyStackException, XMLExcepts::ElemStack_EmptyStack);
>
> //
> // If they want to add to the parent, then we have to have at least two
> // elements on the stack.
> //
> if (toParent && (fStackTop < 2))
> ThrowXML(NoSuchElementException,
> XMLExcepts::ElemStack_NoParentPushed);
>
> // Get a convenience pointer to the stack top row
> StackElem* curRow = toParent
> ? fStack[fStackTop - 2] : fStack[fStackTop - 1];
>
> // See if we need to expand this row's child array
> if (curRow->fChildCount == curRow->fChildCapacity)
> {
> // Increase the capacity by a quarter and allocate a new row
> const unsigned int newCapacity = curRow->fChildCapacity ?
> (unsigned
> int)(curRow->fChildCapacity * 1.25) :
> 32;
> QName** newRow = new QName*[newCapacity];
>
> //
> // Copy over the old contents. We don't have to initialize the new
> // part because The current child count is used to know how much of
> // it is valid.
> //
> // Only both doing this if there is any current content, since
> // this code also does the initial faulting in of the array when
> // both the current capacity and child count are zero.
> //
> if (curRow->fChildCount)
> {
> unsigned int index = 0;
> for (; index < curRow->fChildCount; index++)
> newRow[index] = curRow->fChildren[index];
> }
>
> // Clean up the old children and store the new info
> delete [] curRow->fChildren;
> curRow->fChildren = newRow;
> curRow->fChildCapacity = newCapacity;
> }
>
> // Add this id to the end of the row's child id array and bump the count
> curRow->fChildren[curRow->fChildCount++] = new QName(child);
>
> // Return the level of the index we just filled (before the bump)
> return curRow->fChildCount - 1;
> }
>
> ElemStack::~ElemStack()
> {
> //
> // Start working from the bottom of the stack and clear it out as we
> // go up. Once we hit an uninitialized one, we can break out.
> //
> for (unsigned int stackInd = 0; stackInd < fStackCapacity; stackInd++)
> {
> // If this entry has been set, then lets clean it up
> if (!fStack[stackInd])
> break;
>
> // Delete the row for this entry, then delete the row structure
> for (unsigned int childIndex = 0; childIndex <
> fStack[stackInd]->fChildCount; ++childIndex)
> delete fStack[stackInd]->fChildren[childIndex];
>
> delete [] fStack[stackInd]->fChildren;
> delete [] fStack[stackInd]->fMap;
> delete fStack[stackInd];
> }
>
> // Delete the stack array itself now
> delete [] fStack;
> }
>
> The bits in red above are the locations where the major leaks are occuring.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> ]
> Sent: 10 July 2001 17:17
> To: [EMAIL PROTECTED]
> Subject: [Bug 2426] - memory leak in parser
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2426
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2426>
>
> *** shadow/2426Sat Jul 7 17:36:31 2001
> --- shadow/2426.tmp.25827 Tue Jul 10 09:17:08 2001
> ***************
> *** 2,8 ****
> | memory leak in parser
> |
>
> +---------------------------------------------------------------------------
> -+
> | Bug #: 2426 Product: Xerces-C
> |
> ! | Status: RESOLVED Version: 1.5
> |
> | Resolution: FIXED Platform: PC
> |
> | Severity: Normal OS/Version: Other
> |
> | Priority: Other Component: DOM
> |
> --- 2,8 ----
> | memory leak in parser
> |
>
> +---------------------------------------------------------------------------
> -+
> | Bug #: 2426 Product: Xerces-C
> |
> ! | Status: CLOSED Version: 1.5
> |
> | Resolution: FIXED Platform: PC
> |
> | Severity: Normal OS/Version: Other
> |
> | Priority: Other Component: DOM
> |
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> *************************************************************************
> This message contains privileged and confidential information intended
> only for the use of the recipient named above. Its contents do not
> constitute a commitment by Strategic Thought Limited ("Strategic
> Thought") unless separately endorsed by an authorised representative
> of Strategic Thought.
>
> Any use, dissemination, distribution, reproduction or unauthorised
> disclosure of this message is prohibited. If you receive this message
> in error, please notify the sender immediately and delete it from your
> computer systems.
>
> Any views expressed in this message are those of the individual sender
> and may not necessarily reflect those of Strategic Thought.
>
> Strategic Thought believes this e-mail and any attachments to be virus
> free. However, the recipient is responsible for ensuring it is virus
> free and Strategic Thought do not accept any responsibility for any
> loss or damage howsoever caused from use of this e-mail, attachments
> or contents.
> *************************************************************************
>
> ---------------------------------------------------------------------
> 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]
