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 "Boris Kolpackov (JIRA)" <xe...@xml.apache.org> on 2009/11/03 08:35:59 UTC

[jira] Closed: (XERCESC-1779) XMLMutexLock waits for infinitely

     [ https://issues.apache.org/jira/browse/XERCESC-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Boris Kolpackov closed XERCESC-1779.
------------------------------------

       Resolution: Fixed
    Fix Version/s: 3.0.1

Assuming this is fixed in 3.0.1. If not please reopen with a test case that reproduces the problem.

> XMLMutexLock waits for infinitely
> ---------------------------------
>
>                 Key: XERCESC-1779
>                 URL: https://issues.apache.org/jira/browse/XERCESC-1779
>             Project: Xerces-C++
>          Issue Type: Bug
>          Components: DOM
>    Affects Versions: 2.7.0
>         Environment: Windows XP, VC6
>            Reporter: Sanish Kanjany
>             Fix For: 3.0.1
>
>
> My program has more than one threads which are having atleast one instance of DOMParser. Some times main thread (not sure about other threads) hangs on XMLPlatformUtils::lockMutex or XMLPlatformUtils::unlockMutex. It is not predictable from which function call it goes to lock. From the function call stack of the waiting thread, its coming from DOMParser::resetCachedGrammarPool.  Here is a sample call stack.
> 0012f288 1200ed6e 01d99988 01278db8 00433b9b xerces_c_2_7!xercesc_2_7::XMLMutexLock::~XMLMutexLock+0xa
> 0012f294 00433b9b 0012f300 12022b75 ffffffff xerces_depdom_2_7!xercesc_2_7::DOMParser::resetCachedGrammarPool+0x4ce
> 0012f2a4 1200f4d6 012aac6c 012ee130 012ce778 xerces_c_2_7!xercesc_2_7::XMLPlatformUtils::atomicDecrement+0xb
> 0012f2b4 12001fb3 00000000 012ee130 00000000 xerces_depdom_2_7!xercesc_2_7::DOMString::operator=+0x66
> 0012f2c8 12002558 012ee130 1201526a 012ee130 xerces_depdom_2_7!xercesc_2_7::AttrImpl::makeChildNode+0x33
> 0012f2d0 1201526a 012ee130 012ccbf0 12014067 xerces_depdom_2_7!xercesc_2_7::AttrImpl::getFirstChild+0x8
> 0012f2dc 12014067 012ee130 012c7d10 00000001 xerces_depdom_2_7!xercesc_2_7::NodeImpl::deleteIf+0x5a
> 0012f2f0 12011d97 012c7d10 012c7d10 0012f374 xerces_depdom_2_7!xercesc_2_7::NamedNodeMapImpl::removeAll+0x47
> 0012f308 12011c6f 00000000 00000000 120152a1 xerces_depdom_2_7!xercesc_2_7::ElementImpl::~ElementImpl+0x37
> 0012f314 120152a1 00000001 012c7d10 012a7c38 xerces_depdom_2_7!xercesc_2_7::ElementImpl::ElementImpl+0xdf
> 00000000 00000000 00000000 00000000 00000000 xerces_depdom_2_7!xercesc_2_7::NodeImpl::deleteIf+0x91
> Is there any limit on the number of simultaneous instances of DOMParser ? What will be the root cause for this issue?
> Thanks,
> Sanish

-- 
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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org