[
https://issues.apache.org/jira/browse/XERCESC-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791149#action_12791149
]
tao xiaochuan commented on XERCESC-1901:
----------------------------------------
it is found that the problem happen in only 64 bit system , i have tested two
32 bit system and one 64 bit system (what i can get in company at present)
32 bit system (no such leak problem)
Linux version 2.6.9-42.0.10.ELsmp (r...@yort.fnal.gov) (gcc version 3.4.5
20051201 (Red Hat 3.4.5-2)) #1 SMP Tue Feb 27 08:38:56 CST 2007
g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
Copyright (C) 2006 Free Software Foundation, Inc.
32 bit system (no such leak problem)
cat /proc/version
Linux version 2.6.18-128.1.1.el5 (mockbu...@hs20-bc1-5.build.redhat.com) (gcc
version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Mon Jan 26 13:59:00 EST 2009
cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
64 bit system (has such leak problem)
cat /proc/version
Linux version 2.6.18-53.1.13.el5 (brewbuil...@hs20-bc1-6.build.redhat.com) (gcc
version 4.1.2 20070626 (Red Hat 4.1.2-14)) #1 SMP Mon Feb 11 13:27:27 EST 2008
cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.1 (Tikanga)
the test code has also been simpled in one file mainNew.cc (ACE is not used
but pthread),see attachment
i do not know whether this is a problem caused by 64 bit system or a problem
special to xerces-c of 64 bit version
> memory address leak when running many threads which will parsing xml files
> --------------------------------------------------------------------------
>
> Key: XERCESC-1901
> URL: https://issues.apache.org/jira/browse/XERCESC-1901
> Project: Xerces-C++
> Issue Type: Bug
> Components: SAX/SAX2
> Affects Versions: 3.0.1
> Environment: Red Hat Enterprise Linux Server release 5.1 (Tikanga)
> -g++ --version : x86_64-redhat-linux-g++ (GCC) 4.1.1 20070105 (Red Hat
> 4.1.1-52)
> Reporter: tao xiaochuan
> Attachments: test.zip
>
>
> when running 5 threads , in each thread a xml file will (for test purpost
> xerces-c-3.0.1\samples\data\long.xml is used)
> be parsed, it is found, by top command , VIRT increase large , by pmap
> command , 3 (some time 4) memory address block about 64 m
> are found , when by 8 threads , there will be 5 (some time 6) such blocks :
> Address Kbytes Mode Offset Device Mapping
> 00002aaab00b9000 64796 ----- 00002aaab00b9000 000:00000 [ anon ]
> ...
> 00002aaab40b9000 64796 ----- 00002aaab40b9000 000:00000 [ anon ]
> ...
> 00002aaab80bb000 64788 ----- 00002aaab80bb000 000:00000 [ anon ]
> these blocks will not be released even after XMLPlatformUtils::Terminate();
> if there is only one thead , there is no such a problem
> chief code structure:
> main(){
> XMLPlatformUtils::Initialize();
> //start many threads
> //wait for alll threads ends
> XMLPlatformUtils::Terminate();
> }
> in each thread :
> while(true){
> ...
>
> auto_ptr<SAXParser> parser( new SAXParser() );
> parser->setDocumentHandler(this); //the handler do nothing but just
> extend from HandlerBase
> parser->setErrorHandler(this); //the handler do nothing but just
> extend from HandlerBase
> parser->setValidationScheme(SAXParser::Val_Never);
> parser->setDoSchema(false);
> parser->setDoNamespaces(true);
> parser->parse(inputFile.c_str());
>
> }
> refer to attachment for detail about the simple test code
> one more related question :
> in the doc , it is said "client application needs to Terminate() (or multiple
> Terminate() in the case where multiple Initialize() have been invoked before"
> , does it also suit for more than one threads ?
> for example :
> thread 1 : XMLPlatformUtils::Initialize(); //A
> thread 1 : do some parsing //B
> thread 2 : XMLPlatformUtils::Initialize(); //C
> thread 2 : do some parsing //D
> thread 1 : do some parsing //E
> thread 1 : XMLPlatformUtils::Terminate(); //F
> thread 2 : do some parsing //G
> thread 1 : XMLPlatformUtils::Terminate(); //H
> }
> since these two api are all static , then does C will affect E and does F
> affect G
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
