Hi Pranav,
At 15.55 02/11/2006 +0530, Pranav, Savkur wrote:
Hello Alberto,
Yes that helped big time! Thanks.
I'm also using the DOMImplementation to form a DOM tree and to get the
DOMElement and DOMDocument as below:
DOMImplementation* impl =
DOMImplementationRegistry::getDOMImplementation(X("Core"))
XERCES_CPP_NAMESPACE::DOMDocument* doc = impl->createDocument(
X("xmlns:xsi=\"http:\/\/www.w3.org\/2001\/XMLSchema-instance\""),// root
element namespace URI.
X("SPG_Root"), // root element name
0);
// document type object (DTD).
DOMNode* m_ppRootDOMNode = doc->getDocumentElement();
DOMDocument* m_ppDOMDocument = doc;
This snippet is in a function.
The m_ppDOMDocument is returned from the function after which it is used
in a lot of places.
Hence,it will not be correct if I do a release on the "doc" variable in
this snippet.Am I right?
Right, or the caller will be accessing a deleted object.
Should I be calling release on the m_ppDOMDocument once I'm done using
the DOM Tree?
Is it not necessary to call a release on the m_ppRootDOMNode?
You need to call release() just once, when you are done with it. If
you are not sure when the DOM tree is no more used, you should wrap
it in a ad-hoc class that supports reference counting and calls
release() when the counter reaches 0.
Alberto
I'm asking you this because the memory validator tool is pointing to the
DOMDocumentImpl for the memory leak as below:
DOMDocumentImpl::DOMDocumentImpl(unsigned short const*, unsigned short
const*,class xerces_2_2::DOMDocumentType*)
Which in turn is shown to be calling
DOMDocumentImpl::allocate(unsigned int)
And this is shown as the ultimate point of the memory leak
Will this be the correct way of doing it?
Thanks,
Pranav
-----Original Message-----
From: Alberto Massari (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 1:52 PM
To: [email protected]
Subject: [jira] Commented: (XERCESC-1279) Memory leak with writeToString
in DOMWriter
[
http://issues.apache.org/jira/browse/XERCESC-1279?page=comments#action_1
2446501 ]
Alberto Massari commented on XERCESC-1279:
------------------------------------------
Yes, you should call release() instead of delete, in order to be sure to
use the proper memory manager
> Memory leak with writeToString in DOMWriter
> -------------------------------------------
>
> Key: XERCESC-1279
> URL: http://issues.apache.org/jira/browse/XERCESC-1279
> Project: Xerces-C++
> Issue Type: Bug
> Affects Versions: 2.5.0
> Reporter: Dee
> Priority: Critical
> Attachments: xerces_leak.JPG
>
>
> Hi All,
> I have a very critical issue and we a re trying to implement this in
our mission critical application..
> I'm trying to use writeToString in DOMWriter using the function
> GetXmlString below ----> I am getting a memory leak proportionate to
the size of document been serialized.
> I'm unable to free up the memory allocated .
> Is it something else we need to do ensure that the leak is closed..
> Kindly suggest..
> std::string GetXmlString(DOMNode *pNode) { std::string sXML = ""; try
> {
> DOMImplementation* impl =
> DOMImplementationRegistry::getDOMImplementation(X("Core"));
> // get the XML string out of the DOM
> DOMWriter *theSerializer = impl->createDOMWriter(); XMLCh *xXml =
> theSerializer->writeToString(*pNode);
> char *pChar = XMLString::transcode(xXml); sXML = pChar;
> XMLString::release(&pChar); XMLString::release(&xXml); delete
> theSerializer; // delete impl; // theSerializer->release(); //delete
> theSerializer; }
> catch(const XMLException& toCatch)
> {
> char *pMsg = XMLString::transcode(toCatch.getMessage());
> XMLString::release(&pMsg);
>
> }
> return sXML;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The new company Nokia Siemens Networks is expected to start
operations by January 1, 2007, subject to customary regulatory
approvals, the completion of standard closing conditions, and the
agreement of a number of detailed implementation steps.
Disclaimer:
This e-mail may contain trade secrets or privileged, undisclosed or
otherwise confidential information. If you have received this e-mail
in error, you are hereby notified that any review, copying or
distribution of it is strictly prohibited. Please inform us
immediately and destroy the original transmittal. Thank you for your
cooperation.
---------------------------------------------------------------------
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]
