Hi Tinny, You wrote:
> I think the fix is to reset fLocalPart to zero before calling
> new, i.e. ...
> Then deleting fLocalPart twice is not a problem, and users can call
> QName::cleanUp().
Of course, this fixes the problem for Qname, but not for the users of Qname.
Look at the following fragment
from XMLElementDecl.cpp:
//
---------------------------------------------------------------------------
// XMLElementDecl: Destructor
//
---------------------------------------------------------------------------
XMLElementDecl::~XMLElementDecl()
{
delete fElementName;
}
//
---------------------------------------------------------------------------
// XMLElementDecl: Setter Methods
//
---------------------------------------------------------------------------v
oid
XMLElementDecl::setElementName(const XMLCh* const prefix
, const XMLCh* const localPart
, const int uriId )
{
delete fElementName;
fElementName = new QName(prefix, localPart, uriId);
^^^^^^^^
}
If new Qname throws bad_alloc due to (temporary) memory shortage, we face
the same problem here: Deleting the instance of XMLElementDecl (what might
happen automatically if it was an auto-variable !) will double-delete and
segfault, not deleting it punches memory. Of course, we also face the same
solution: reset fElementName to zero after deleting it. I'm not sure whether
it's a good idea to open a bugzilla ticket for every similar condition, as i
doubt there are quite a lot ( just scan through XMLElementDecl... ).
Instead, i'd suggest to preventively look at every new and delete statement
in the code and check for this.
> But generally speaking, I agree that there may be better way
> to redesign the new / delete mechanism in Xerces-C++.
> I think we need to gather more design suggestion from the
> Open Source Community for the best proposal.
IMHO, this sounds very reasonable. As soon as i have a good looking idea (or
find somebody else's one) i'll post it here.
Unfortunately, we cannot use Xerces as long as we cannot be reasonably sure
that it stands temporary out-of-memory conditions, and there are about 800
delete statements in the code. For this reason, my current strategy is to
strip-off all parts the we do not actually need, and then check the
remaining delete statements. As we want to use solely IDOM for performance
reasons, i first tried to remove the dom component. Alas, i found that i had
to drop schema-validation as well because it's hard-wired to use dom for
parsing the schema 8-(. And, removing schema-validation is not as trivial as
it looked at the first glance, there are lots of dependencies... What about
making schame-validation configurable wrt. which domimplemantation to use ?
thanks for your reply, Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
