well, not to stray from your original post, but going forward, couldn't we
tackle this by trying to lock down faulty pieces of code one at a time, i.e.
anytime delete is called on a pointer variable which is a member of a class,
and if we are NOT in the destructor, then set this pointer to zero. this
way, a double delete will be harmless, and the destructor can be called
safely. i don't know what other such issues you saw, but it seems in this
case, a simple fix of setting the poiner to NULL would fix your problems?
i.e.
> void QName::setLocalPart(const XMLCh* localPart)
> {
> unsigned int newLen;
>
> newLen = XMLString::stringLen(localPart);
> if (!fLocalPartBufSz || (newLen > fLocalPartBufSz))
> {
> delete [] fLocalPart;
flocalPart = 0; // set the pointer to zero in case the following new
fails
> fLocalPartBufSz = newLen + 8;
> fLocalPart = new XMLCh[fLocalPartBufSz + 1];
> ^^^
> }
> XMLString::moveChars(fLocalPart, localPart, newLen + 1);
> }
If there aren't "too" many such pieces of code, they can probably be
identified as encountered and fixed in a manner similar to the above?
Samar
-----Original Message-----
From: Cornelius, Martin [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 08, 2002 12:17 PM
To: 'xerces-c-dev mailing list'
Subject: Again: Xerces not server proof ?
Some weeks ago i posted a message on this list, where i pointed out that
Xerces, as it currently is, cannot survive temporary out-of-memory
conditions without punching memory leaks, and thus looks not really fit to
be used in a 'cruel-real-world' server application. ( The Subject was :
"Xerces in an application where fail of new must be tolerated : Impossible
?" )
So far, i have seen no followup on this, and thus would like to ask the
development team: Are you at all interested to address this issue, or do you
think i'm completely wrong ?
Apologize my tedious manner, and thanks for any enlightening,
Martin
P.S, for reference, this is the original post:
> -----Original Message-----
>
> Hi there,
>
> we are currently reasoning about whether it is possible to
> use Xerces in a
> multithreaded server Application, whrere failure of memory
> allocation must
> be tolerated. More exactly: failure of global operator new or
> malloc() may
> always happen when the server is heavy loaded, but they will
> never terminate
> the server. Of course, the particular client request in whose
> context the
> failed allocation happened must be aborted in this case. However, this
> abortion will proceed in a controlled way and MUST NEVER lead
> to memory
> leaks.
>
> AFAICS, the current coding of Xerces does not fulfill this
> requirement. E,g,
> look at this code fragments from class QName:
>
> class XMLUTIL_EXPORT QName
> {
> // ....
> private :
> XMLCh* fPrefix;
> XMLCh* fLocalPart;
> XMLCh* fRawName;
> };
>
> fPrefix, fLocalPart, and fRawname are initialized to zero,
> and later on
> global operator new[] is used to allocate buffers. In the destructor,
> cleanup() is called:
>
> void QName::cleanUp()
> {
> delete [] fLocalPart;
> delete [] fPrefix;
> delete [] fRawName;
> }
>
> So far, so good. But now look at another invocation of new in
> this member
> function:
>
> 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.
> Unfortunately, code like this seems to be present many times
> in Xerces 8-(.
> Worse, Qname is a basic building block, and all users of Qname seem to
> ignore totally that Qname might throw bad_alloc.
>
> These are several solutions i can currently imagine, orderded
> by my personal
> preference:
>
> 1 - inspect the complete code for possible memory leaks
> caused by bad_alloc
> execeptions, and try to fix this using try/catch statements.
> AFAICS, this is
> a quite daunting and error-prone task, as basic classes like
> Qname are used
> in many places and may throw bad_alloc in most operations.
>
> 2 - Encourage users of Xerces to override global new and
> delete if they want
> applications to survive bad_malloc. This does not require to
> modify Xerces,
> but it may be undesirable or even impossible in many
> circumstances. IMHO, a
> library designed for common use should not require it's users
> to do this.
>
> 3 - Throughout Xerces, replace ALL occurences of new and
> delete by calls to
> suitable allocator classes/functions, and never use global
> new and delete
> outside of this allocators. The IDOM has already made steps in this
> direction by using IDDocumentImpl as some kind of arena
> allocator ( that
> does not support deletion ). Of course, this is also a boring
> task, but in
> contrast to solution 1 the effort can be easily estimated
> (simply count the
> new and delete invocations) and a result that fulfills the
> requirement is
> guaranteed. Currently i think, this is the way to go.
>
> Please, send me your comments ! Martin
---------------------------------------------------------------------
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]
