[ http://issues.apache.org/jira/browse/XALANC-612?page=comments#action_12372724 ]
David Bertoni commented on XALANC-612: -------------------------------------- Have you tried building Xerces-C without thread support? I do know there were some problems getting pthreads to work on some versions of FreeBSD, but it would be a bug with Xerces-C, and not with Xalan-C. If you're not using threads, you will also get a bit of a performance boost, since the there will be less synchronization. > 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]
