Martin,
I agree that we should fix any potential memory leak that remains after
exception scenario, and that Xerces-C++ should be exception-safe. In fact we do
try to eliminate them. Bugzilla bug like 3565 was an example of such kind of
leak fix. But our current approach is to fix them one by one whenever it is
discovered and reported in bugzilla by any users.
Regarding your earlier example in QName:
> void QName::setLocalPart(const XMLCh* localPart)
> {
> unsigned int newLen;
> newLen = XMLString::stringLen(localPart);
> if (!fLocalPartBufSz || (newLen > fLocalPartBufSz))
> {
> delete [] fLocalPart;
> fLocalPartBufSz = newLen + 8;
> fLocalPart = new XMLCh[fLocalPartBufSz + 1];
> ^^^
> }
> XMLString::moveChars(fLocalPart, localPart, newLen + 1);
> }
> If this new fails and raises an exception, we run into trouble: If we call
> Qname's destructor or call Qname::cleanUp directly, fLocalPart is deleted
> twice, if we do not, we get two memory leaks for fPrefix and fRawname.
I think the fix is to reset fLocalPart to zero before calling new, i.e.
if (!fLocalPartBufSz || (newLen > fLocalPartBufSz))
{
delete [] fLocalPart;
fLocalPartBufSz = newLen + 8;
/* =>add this ==>*/ fLocalPart = 0;
fLocalPart = new XMLCh[fLocalPartBufSz + 1];
^^^
}
Then deleting fLocalPart twice is not a problem, and users can call
QName::cleanUp().
But generally speaking, I agree that there may be better way to redesign the new
/ delete mechanism in Xerces-C++. But as a 'cruel-real-world' server
application, performance is also an important issue. And putting try / catch
block everywhere when new is called (the Sol'n #1) will definitely hit
performance badly. And the IDOM approach (Sol'n #3) is only good for
single-thread scenario. To support multi-thread scenario, we have to adopt some
sort of locking mechanism which may have an impact on performance as well.
I think we need to gather more design suggestion from the Open Source Community
for the best proposal. Any suggestion / feedback from the mailing list is
welcome.
But in the meantime, as a short term solution, please report any findings (like
the QName problem that you found) in bugzilla, and we can address each of them
individually.
Thanks!
Tinny
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
