You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "David Bertoni (JIRA)" <xa...@xml.apache.org> on 2006/06/03 20:46:30 UTC
[jira] Commented: (XALANC-612) XMLMutex fails from XSLT extension
[ http://issues.apache.org/jira/browse/XALANC-612?page=comments#action_12414601 ]
David Bertoni commented on XALANC-612:
--------------------------------------
I have confirmed that this is a problem with Xerces-C on FreeBSD. It looks like pthread support is not working there.
> XMLMutex fails from XSLT extension
> ----------------------------------
>
> Key: XALANC-612
> URL: http://issues.apache.org/jira/browse/XALANC-612
> Project: XalanC
> Type: Bug
> Versions: 1.6
> Environment: FreeBSD 6.0 (Release), libc++ 5, libpthread.so.2
> Reporter: Shawn Price
>
> Our application makes heavy use of XSL transformation supported by custom XSLT extension
> functions to process documents. The extension function I'm current trying to debug returns
> a -3 error ("Could not make mutex") back to XalanTransformer::transform(). In tracking down
> the problem, I've traced it to a function call where we create an instance of a custom
> NodeSetProxy implementation we create to return the XMLObjectPtr from the function.
> The constructor for this class is as follows:
> NodeSetProxy::NodeSetProxy(
> MemoryManagerType& manager,
> DOMDocument* document) :
> XNodeSetBase(manager),
> m_wrapper(
> manager,
> document,
> true,
> true),
> m_proxy(manager, &m_wrapper)
> {
> //irrelavent initialization here
> }
> The problem is that the constructor for XercesDocumentWrapper (the call "m_wrapper(manager,
> document, true, true)" above) ultimately results in an instantiation of XMLMutex, which, in
> turn, calls XMLPlatformUtils::makeMutex() and subsequently fails with error "could not make
> mutex" from the underlying platform POSIX threads library. The backtrace from gdb looks
> like this:
> #0 0x286d86ad in xercesc_2_6::XMLMutex::XMLMutex ()
> from /casper/lib/libxerces-c.so.26
> #1 0x2833fde6 in
> xalanc_1_9::XercesLiaisonXalanDOMStringPool::XercesLiaisonXalanDOMStringPool () from
> /casper/lib/libxalan-c.so
> #2 0x2833fe51 in xalanc_1_9::XercesLiaisonXalanDOMStringPool::create ()
> from /casper/lib/libxalan-c.so
> #3 0x2833863b in xalanc_1_9::XercesDocumentWrapper::XercesDocumentWrapper ()
> from /casper/lib/libxalan-c.so
> #4 0x08060ac8 in NodeSetProxy::NodeSetProxy ()
> #5 0x08052aa5 in DbdSqlQueryFunction::execute ()
> #6 0x282ecb43 in xalanc_1_9::XPathEnvSupportDefault::extFunction ()
> from /casper/lib/libxalan-c.so
> #7 0x28465169 in xalanc_1_9::XSLTProcessorEnvSupportDefault::extFunction ()
> from /casper/lib/libxalan-c.so
> #8 0x28411a80 in xalanc_1_9::StylesheetExecutionContextDefault::extFunction ()
> from /casper/lib/libxalan-c.so
> #9 0x282e1a09 in xalanc_1_9::XPath::runExtFunction ()
> from /casper/lib/libxalan-c.so
> #10 0x282dd074 in xalanc_1_9::XPath::executeMore ()
> from /casper/lib/libxalan-c.so
> #11 0x283ad595 in xalanc_1_9::ElemVariable::startElement ()
> from /casper/lib/libxalan-c.so
> #12 0x283a97f6 in xalanc_1_9::ElemTemplateElement::execute ()
> ---Type <return> to continue, or q <return> to quit---
> from /casper/lib/libxalan-c.so
> #13 0x2843ce16 in xalanc_1_9::StylesheetRoot::process ()
> from /casper/lib/libxalan-c.so
> #14 0x28454293 in xalanc_1_9::XSLTEngineImpl::process ()
> from /casper/lib/libxalan-c.so
> #15 0x2848f99c in xalanc_1_9::XalanTransformer::doTransform ()
> from /casper/lib/libxalan-c.so
> #16 0x0806013e in xalanc_1_9::XalanTransformer::transform ()
> #17 0x0805fd99 in CasperXmlProcessor::processRequest ()
> #18 0x0805e82c in DatabaseDaemon::process ()
> #19 0x0805fc5d in main ()
> I have yet to go through the Xerces-C++ code base, but the error seems to be propagating
> from a failed call to pthread_mutex_init. One way or another, there is a logic bug, and I
> don't think it's in our code. We're using Xerces-C 2.6, Xalan-C 1.9, libpthread.so.2, and libstdc++.so.5.
--
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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org