You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Gareth Reakes (JIRA)" <xe...@xml.apache.org> on 2005/11/24 15:49:56 UTC
[jira] Commented: (XERCESC-1529) Memory Leak in Xerces-2.7.0 at xercesc_2_7::IconvLCPTranscoder::transcode
[ http://issues.apache.org/jira/browse/XERCESC-1529?page=comments#action_12358462 ]
Gareth Reakes commented on XERCESC-1529:
----------------------------------------
Hi, many people report leaks that are in fact not leaks. For example, the documentation for transcode states that you are responsible for delteing what comes back. I don't know what you are trying to do, but are you sure you want to use transcode at all?
Gareth
> 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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org