[ http://issues.apache.org/jira/browse/XALANC-612?page=comments#action_12372726 ]
David Bertoni commented on XALANC-612: -------------------------------------- I should also point out that you can pass "false" for the third parameter of the XercesDocumentWrapper constructor, and you won't get to this code, because the XercesDocumentWrapper instance will not have a synchronized string pool. If you're not sharing these node sets between threads, that's probably what you want anyway. > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
