[ http://issues.apache.org/jira/browse/XERCESC-1529?page=all ]
Alberto Massari resolved XERCESC-1529:
--------------------------------------
Resolution: Invalid
>From the stack it's clear that XMLString::transcode is invoked from the user's
>code (countChildElements(xercesc_2_7::DOMNode*,
>Pegasus::Array<Pegasus::CIMParamValue>) ), so the leak is caused by a missing
>call to XMLString::release
Alberto
> Memory Leak in Xerces-2.7.0 at xercesc_2_7::IconvLCPTranscoder::transcode
> -------------------------------------------------------------------------
>
> Key: XERCESC-1529
> URL: http://issues.apache.org/jira/browse/XERCESC-1529
> Project: Xerces-C++
> Type: Bug
> Components: DOM
> Versions: 2.7.0
> Environment: RHEL3 U5, RHEL4 U1
> Reporter: Sujoy Sarkar
> Priority: Critical
>
> Multiple blocks of memory leak is detected through Valgrind memory leak
> detection tool from Xerces 2.7.0 library.
> The leaks are being detected in both RHEL3 U5, RHEL4 U1 flavors of Linux.
> Given below is the excerpt of one such valgrind report showing leaks in
> xerces 2.7:
> ==4823== 835 bytes in 167 blocks are definitely lost in loss record 7838 of
> 7952
> ==4823== at 0x341498F6: operator new[](unsigned) (vg_replace_malloc.c:138)
> ==4823== by 0x37BEDE35:
> xercesc_2_7::IconvLCPTranscoder::transcode(unsigned short const*)
> (IconvTransService.cpp:307)
> ==4823== by 0x37CCC718: xercesc_2_7::XMLString::transcode(unsigned short
> const*) (XMLString.cpp:541)
> ==4823== by 0x37A0898E: countChildElements(xercesc_2_7::DOMNode*,
> Pegasus::Array<Pegasus::CIMParamValue>) (DOMParser.cpp:130)
> ==4823== by 0x37A08429: countChildElements(xercesc_2_7::DOMNode*,
> Pegasus::Array<Pegasus::CIMParamValue>) (DOMParser.cpp:151)
> ==4823== by 0x37A09082: ParseOcXMLData(char*) (DOMParser.cpp:290)
> ==4823== by 0x37A0C289: OCEvtCallBack(unsigned long, unsigned long long,
> unsigned long long) (OCEventProvider.cpp:222)
> ==4823== by 0x3467A9F1: saEvtDispatch (saEvtFmk.c:1346)
> ==4823== by 0x37A0C528: GenericAisInitCall(void*) (OCEventProvider.cpp:356)
> ==4823== by 0x3468DDE7: start_thread (in /lib/tls/libpthread-0.60.so)
> ==4823== by 0x34862939: clone (in /lib/tls/libc-2.3.2.so)
> In our application we are heavily dependant on DOM Node Processing capability
> of Xerces and our application being a server thread we are having difficulty
> to place our application in production with this kind of fundamental memory
> leak as a known problem.
> There is no scope for us to minimize or avoid this calls as well, since it is
> closely coupled in a recursive call which forms the backbone of our
> application.
> Shall be great if this is fixed soon.
> Sujoy Sarkar
> Hewlett-Packard Co.
> Bangalore - India
> +91 80 2205 3084
> Mobile: 09845298741
>
--
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]
