You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Pete Robbins (JIRA)" <tu...@ws.apache.org> on 2006/10/11 15:40:21 UTC
[jira] Created: (TUSCANY-825) Memory leak in SDOXMLString
Memory leak in SDOXMLString
---------------------------
Key: TUSCANY-825
URL: http://issues.apache.org/jira/browse/TUSCANY-825
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Pete Robbins
Assigned To: Pete Robbins
Fix For: Cpp-current
One of our PHP users has reported a problem with leaking memory from
libxml2. I started to investigate, but realised that the issue is
independent of PHP, and can be reproduced in a standalone Tuscany
environment. The issue is that memory allocated by libxml2 is not being
freed, so he is seeing a memory leak growing with each invocation.
For example, if we take a small schema:
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="courses">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="course" minOccurs="0"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="description"
type="xsd:string"/>
<xsd:element name="credits" type="xsd:decimal"/>
<xsd:element name="lastmodified"
type="xsd:dateTime" minOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="cid" type="xsd:ID"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
and a trivial function to load it:
void load_schema(char *name)
{
DataFactoryPtr mdg = DataFactory::getDataFactory();
XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg);
xsh->defineFile(name);
xsh = NULL;
mdg = NULL;
}
(I added the last two lines to try to encourage the reference-counting
pointers to do their work, but they made no difference to the outcome)
then use libxml features to check the memory usage:
int main (int argc, char** argv)
{
xmlInitParser();
load_schema(argv[1]);
xmlCleanupParser();
xmlMemoryDump();
return 0;
}
(note: in order to use these libxml functions, you must recompile with
debug=yes mem_debug=yes)
We see the following output in libxml's .memdump file:
MEMORY ALLOCATED : 108, MAX was 13687
BLOCK NUMBER SIZE TYPE
0 984 3 malloc() in none(0) "ID"
1 981 4 malloc() in none(0) "xsd"
2 971 3 malloc() in none(0) "ID"
3 968 4 malloc() in none(0) "xsd"
4 875 9 malloc() in none(0) "dateTime"
5 872 4 malloc() in none(0) "xsd"
6 861 9 malloc() in none(0) "dateTime"
7 858 4 malloc() in none(0) "xsd"
8 770 8 malloc() in none(0) "decimal"
9 767 4 malloc() in none(0) "xsd"
10 756 8 malloc() in none(0) "decimal"
11 753 4 malloc() in none(0) "xsd"
12 677 7 malloc() in none(0) "string"
13 674 4 malloc() in none(0) "xsd"
14 663 7 malloc() in none(0) "string"
15 660 4 malloc() in none(0) "xsd"
16 584 7 malloc() in none(0) "string"
17 581 4 malloc() in none(0) "xsd"
18 570 7 malloc() in none(0) "string"
19 567 4 malloc() in none(0) "xsd"
I did this with the M1 release of Tuscany SDO C++ and libxml2 2.6.26.
The good news is that this leak has decreased a lot from an earlier
release he tried previously.
I hope this test seems valid to you. If so, any chance of removing the
remaining leaks? Even better, could this kind of testing be incorporated
in the process?
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Resolved: (TUSCANY-825) Memory leak in SDOXMLString
Posted by "Pete Robbins (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-825?page=all ]
Pete Robbins resolved TUSCANY-825.
----------------------------------
Resolution: Fixed
> Memory leak in SDOXMLString
> ---------------------------
>
> Key: TUSCANY-825
> URL: http://issues.apache.org/jira/browse/TUSCANY-825
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Pete Robbins
> Assigned To: Pete Robbins
> Fix For: Cpp-current
>
>
> One of our PHP users has reported a problem with leaking memory from
> libxml2. I started to investigate, but realised that the issue is
> independent of PHP, and can be reproduced in a standalone Tuscany
> environment. The issue is that memory allocated by libxml2 is not being
> freed, so he is seeing a memory leak growing with each invocation.
> For example, if we take a small schema:
> <?xml version="1.0"?>
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <xsd:element name="courses">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="course" minOccurs="0"
> maxOccurs="unbounded">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="title" type="xsd:string"/>
> <xsd:element name="description"
> type="xsd:string"/>
> <xsd:element name="credits" type="xsd:decimal"/>
> <xsd:element name="lastmodified"
> type="xsd:dateTime" minOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="cid" type="xsd:ID"/>
> </xsd:complexType>
> </xsd:element>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> </xsd:schema>
> and a trivial function to load it:
> void load_schema(char *name)
> {
> DataFactoryPtr mdg = DataFactory::getDataFactory();
> XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg);
> xsh->defineFile(name);
> xsh = NULL;
> mdg = NULL;
> }
> (I added the last two lines to try to encourage the reference-counting
> pointers to do their work, but they made no difference to the outcome)
> then use libxml features to check the memory usage:
> int main (int argc, char** argv)
> {
> xmlInitParser();
> load_schema(argv[1]);
> xmlCleanupParser();
> xmlMemoryDump();
> return 0;
> }
> (note: in order to use these libxml functions, you must recompile with
> debug=yes mem_debug=yes)
> We see the following output in libxml's .memdump file:
> MEMORY ALLOCATED : 108, MAX was 13687
> BLOCK NUMBER SIZE TYPE
> 0 984 3 malloc() in none(0) "ID"
> 1 981 4 malloc() in none(0) "xsd"
> 2 971 3 malloc() in none(0) "ID"
> 3 968 4 malloc() in none(0) "xsd"
> 4 875 9 malloc() in none(0) "dateTime"
> 5 872 4 malloc() in none(0) "xsd"
> 6 861 9 malloc() in none(0) "dateTime"
> 7 858 4 malloc() in none(0) "xsd"
> 8 770 8 malloc() in none(0) "decimal"
> 9 767 4 malloc() in none(0) "xsd"
> 10 756 8 malloc() in none(0) "decimal"
> 11 753 4 malloc() in none(0) "xsd"
> 12 677 7 malloc() in none(0) "string"
> 13 674 4 malloc() in none(0) "xsd"
> 14 663 7 malloc() in none(0) "string"
> 15 660 4 malloc() in none(0) "xsd"
> 16 584 7 malloc() in none(0) "string"
> 17 581 4 malloc() in none(0) "xsd"
> 18 570 7 malloc() in none(0) "string"
> 19 567 4 malloc() in none(0) "xsd"
> I did this with the M1 release of Tuscany SDO C++ and libxml2 2.6.26.
> The good news is that this leak has decreased a lot from an earlier
> release he tried previously.
> I hope this test seems valid to you. If so, any chance of removing the
> remaining leaks? Even better, could this kind of testing be incorporated
> in the process?
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-825) Memory leak in SDOXMLString
Posted by "Pete Robbins (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-825?page=comments#action_12441458 ]
Pete Robbins commented on TUSCANY-825:
--------------------------------------
It is caused by the SDOXMLString::substring method creating 2 copies of the string and only freeing one of them. this method is called when parsing the QName string in type="fred:joe" so we end up with an extra "fred" and "joe" when this is called.
> Memory leak in SDOXMLString
> ---------------------------
>
> Key: TUSCANY-825
> URL: http://issues.apache.org/jira/browse/TUSCANY-825
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
> Affects Versions: Cpp-current
> Reporter: Pete Robbins
> Assigned To: Pete Robbins
> Fix For: Cpp-current
>
>
> One of our PHP users has reported a problem with leaking memory from
> libxml2. I started to investigate, but realised that the issue is
> independent of PHP, and can be reproduced in a standalone Tuscany
> environment. The issue is that memory allocated by libxml2 is not being
> freed, so he is seeing a memory leak growing with each invocation.
> For example, if we take a small schema:
> <?xml version="1.0"?>
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <xsd:element name="courses">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="course" minOccurs="0"
> maxOccurs="unbounded">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="title" type="xsd:string"/>
> <xsd:element name="description"
> type="xsd:string"/>
> <xsd:element name="credits" type="xsd:decimal"/>
> <xsd:element name="lastmodified"
> type="xsd:dateTime" minOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="cid" type="xsd:ID"/>
> </xsd:complexType>
> </xsd:element>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> </xsd:schema>
> and a trivial function to load it:
> void load_schema(char *name)
> {
> DataFactoryPtr mdg = DataFactory::getDataFactory();
> XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg);
> xsh->defineFile(name);
> xsh = NULL;
> mdg = NULL;
> }
> (I added the last two lines to try to encourage the reference-counting
> pointers to do their work, but they made no difference to the outcome)
> then use libxml features to check the memory usage:
> int main (int argc, char** argv)
> {
> xmlInitParser();
> load_schema(argv[1]);
> xmlCleanupParser();
> xmlMemoryDump();
> return 0;
> }
> (note: in order to use these libxml functions, you must recompile with
> debug=yes mem_debug=yes)
> We see the following output in libxml's .memdump file:
> MEMORY ALLOCATED : 108, MAX was 13687
> BLOCK NUMBER SIZE TYPE
> 0 984 3 malloc() in none(0) "ID"
> 1 981 4 malloc() in none(0) "xsd"
> 2 971 3 malloc() in none(0) "ID"
> 3 968 4 malloc() in none(0) "xsd"
> 4 875 9 malloc() in none(0) "dateTime"
> 5 872 4 malloc() in none(0) "xsd"
> 6 861 9 malloc() in none(0) "dateTime"
> 7 858 4 malloc() in none(0) "xsd"
> 8 770 8 malloc() in none(0) "decimal"
> 9 767 4 malloc() in none(0) "xsd"
> 10 756 8 malloc() in none(0) "decimal"
> 11 753 4 malloc() in none(0) "xsd"
> 12 677 7 malloc() in none(0) "string"
> 13 674 4 malloc() in none(0) "xsd"
> 14 663 7 malloc() in none(0) "string"
> 15 660 4 malloc() in none(0) "xsd"
> 16 584 7 malloc() in none(0) "string"
> 17 581 4 malloc() in none(0) "xsd"
> 18 570 7 malloc() in none(0) "string"
> 19 567 4 malloc() in none(0) "xsd"
> I did this with the M1 release of Tuscany SDO C++ and libxml2 2.6.26.
> The good news is that this leak has decreased a lot from an earlier
> release he tried previously.
> I hope this test seems valid to you. If so, any chance of removing the
> remaining leaks? Even better, could this kind of testing be incorporated
> in the process?
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org