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]
