[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
