DO NOT REPLY [Bug 10724] New: - Application utilizes CPU nearly 100% during parsing XML data in memory

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10724>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10724

Application utilizes CPU nearly 100% during parsing XML data in memory

           Summary: Application utilizes CPU nearly 100% during parsing XML
                    data in memory
           Product: Xerces-C++
           Version: 1.4
          Platform: Other
        OS/Version: AIX
            Status: NEW
          Severity: Major
          Priority: Other
         Component: DOM
        AssignedTo: xerces-c-dev@xml.apache.org
        ReportedBy: somsakc@th.ibm.com


Dear Support,

Enviroment:
AIX 4.3.3
xerces C++ 1.3
VitualAge C++ compiler V5.0

I have a problem about application which run on AIX 4.3.3 and use xerces C++ 
library version 1.3. I wrote C++ application with pthread and use xerces and 
XML parsing in memory. Application has run daily on production. And I found 
that some day application might hang and utilize CPU near 100%. I use dbx 
command on AIX to attach process and dump stack trace as below. I found a 
thread which seems stuck in function or in loop infinity.

NodeImpl::deleteIf(NodeImpl*)(thisNode = 0x201be788), line 192 in "NodeImpl.cpp"
unnamed block $b644, line 148 in "NamedNodeMapImpl.cpp"
unnamed block $b643, line 148 in "NamedNodeMapImpl.cpp"
removeAll()(0x201b4778), line 148 in "NamedNodeMapImpl.cpp"
~ElementImpl()(0x201be218, 0x3, 0x0), line 98 in "ElementImpl.cpp"
NodeImpl::deleteIf(NodeImpl*)(thisNode = 0x201be218), line 208 in "NodeImpl.cpp"
unnamed block $b674, line 206 in "NodeImpl.cpp"
NodeImpl::deleteIf(NodeImpl*)(thisNode = 0x201bc1b8), line 206 in "NodeImpl.cpp"
unnamed block $b674, line 206 in "NodeImpl.cpp"
NodeImpl::deleteIf(NodeImpl*)(thisNode = 0x20195988), line 206 in "NodeImpl.cpp"
unreferenced()(0x20195988), line 505 in "DocumentImpl.cpp"
removeRef(RefCountedImpl*)(0x20195988), line 117 in "RefCountedImpl.cpp"
NodeImpl::unreferenced()(this = 0x201bc1b8), line 354 in "NodeImpl.cpp"
removeRef(RefCountedImpl*)(0x201bc1b8), line 117 in "RefCountedImpl.cpp"

DOM_Node.operator=(const DOM_Node&)(0x2030c8e4, 0x2030c2f8), line 125 
in "DOM_Node.cpp"
DOM_Element.operator=(const DOM_Element&)(0x2030c8e4, 0x2030c2f8), line 117 
in "DOM_Element.cpp"

parseXML__16DXMLMemoryParserFv(0x2030c880) at 0x1004c2e0
parseXML__16DXMLMemoryParserFPCcCiPCcCi(0x2030c880, 0x20200d19, 0xa0, 
0x201b1b19, 0xf) at 0x1004cd60
parse__15ASRequestParserFCiRCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ
2_3std9allocatorXTc__(0x2030c880, 0x0, 0x2030ca60) at 0x10232570
run__16ASRequestMonitorFv(0x201a5318) at 0x1022a46c
entryPoint__6ThreadFPv(0x201a5318) at 0x1007fff4
pthread._pthread_body(??) at 0xd00080c8

I try to reproduce the problem by sending XML data to that thread, but the 
problem is not occure. Whereas I let the application to run on production it 
still hang sometime. So I would like you to analyze the problem. Suggestion? 
And is it a bug in version 1.3?

Thank you.
Regards,
Somsak Chartsrisak
somsakc@th.ibm.com

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org