[
https://issues.apache.org/jira/browse/XERCESC-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790526#action_12790526
]
tao xiaochuan commented on XERCESC-1901:
----------------------------------------
hello . the leak problem we focus on can not be detected by valgrind , since
it is not caused by not using new and delete properly , the memory leak
related to ACE TASK found by valgrind is not the core of the problem , sorry
for that the example
code has made some confusing by it is not a good code
a leak case which can not be found by vargrind :
for example , for thread which is not PTHREAD_CREATE_DETACHED, it will casue
below leak when its parent thread do not join it after it finish :
Address Kbytes Mode Offset
Device Mapping
0000000040001000 10240 rwx-- 0000000040001000 000:00000 [ anon ]
such memory address block is gotten by mmap api , not by new , valgrind can
not detect such leak
for my problem, i have used valgrind already at beginning and also use strace
command to trace mmap calling , but nothing found , then there is the problem
reported
can you repeat the test (for example 5 thread nor more ) and watch it by pmap
( copy xerces-c-3.0.1\samples\data\long.xml to Test1.xml ~ Test10.xml , or
change all TestN.xml to long.xml in main.cc)
and you can also fiind that when there is only one thread , there will be no
such 64 m block no matter how long it will run.
> 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: [email protected]
For additional commands, e-mail: [email protected]
