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 "Sujoy Sarkar (JIRA)" <xe...@xml.apache.org> on 2005/11/24 13:51:55 UTC
[jira] Created: (XERCESC-1529) Memory Leak in Xerces-2.7.0 at xercesc_2_7::IconvLCPTranscoder::transcode
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
[jira] Commented: (XERCESC-1529) Memory Leak in Xerces-2.7.0 at xercesc_2_7::IconvLCPTranscoder::transcode
Posted by "Gareth Reakes (JIRA)" <xe...@xml.apache.org>.
[ 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
[jira] Resolved: (XERCESC-1529) Memory Leak in Xerces-2.7.0 at xercesc_2_7::IconvLCPTranscoder::transcode
Posted by "Alberto Massari (JIRA)" <xe...@xml.apache.org>.
[ 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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org