[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xerces-c-dev
Subject:    [jira] Commented: (XERCESC-1529) Memory Leak in Xerces-2.7.0 at xercesc_2_7::IconvLCPTranscoder::tra
From:       "Gareth Reakes (JIRA)" <xerces-c-dev () xml ! apache ! org>
Date:       2005-11-24 14:49:56
Message-ID: 173944605.1132843796002.JavaMail.jira () ajax ! apache ! org
[Download RAW message or body]

    [ 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


[prev in list] [next in list] [prev in thread] [next in thread]