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]
