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=13153>. 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=13153 Core on repeatedly evaluating an XPath expression Summary: Core on repeatedly evaluating an XPath expression Product: XalanC Version: 1.4.x Platform: Sun OS/Version: Solaris Status: NEW Severity: Blocker Priority: Other Component: XPathC AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am observing a difference in behavior in an example between Xalan 1.3 and Xalan 1.4. The 1.3 example returns the expected result, the 1.4 doesn't. The expression in question is: Context: attrLists Path expr: class/mo[@moid="3351"]/mname the SimpleXPathAPI example in both releases returns the correct result. This is a one time only execution, where the expression is passed on the command line, and only queries the DOM once. The problem occurs when attempting evaluate this particular XPath multiple times against the same DOM instance. The attached example is a version of the SimpleXPathAPI example modified to read the expressions from a file and apply them in turn to a single DOM instance. 1.3: don't core and get the expected node reference both times 1.4: get the expected node reference the first time, core the second time This was reproduced on: SunOS sol8bld 5.8 Generic_108528-14 sun4u sparc SUNW,Sun-Fire-880 CC: Forte Developer 7 C++ 5.4 2002/03/09 To exercise the example: source env_13.csh make -f Makefile_13 clean all ./runTest Expected output: ------------------------------------- Context: attrLists Path: class/mo[@moid="3351"]/mname Context: attrLists Path: class/mo[@moid="3351"]/mname Context: attrLists Path: class/mo[@moid="3351"]/mname source env_14.csh make -f Makefile_14 clean all ./runTest Output: ------------------------------------- Context: attrLists Path: class/mo[@moid="3351"]/mname Context: attrLists Path: class/mo[@moid="3351"]/mname Segmentation Fault - core dumped The stack is: ------------------------------------- sol8bld:25 % dbx sol/XPathTest core For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.0' in your .dbxrc Reading XPathTest core file header read successfully Reading ld.so.1 Reading libxalan-c1_4_0.so Reading libxerces-c.so.21 Reading libc.so.1 Reading libgen.so.1 Reading libCstd.so.1 Reading libCrun.so.1 Reading libm.so.1 Reading libw.so.1 Reading libpthread.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libCstd_isa.so.1 Reading libc_psr.so.1 Reading libthread.so.1 detected a multithreaded program t@1 (l@1) terminated by signal SEGV (no mapping at the fault address) 0x00000000: <bad address 0x0> Current function is applyXPath 111 const XObjectPtr theResult( (dbx) where current thread: t@1 [1] 0x0(0xffbee148, 0x489f0, 0x52410, 0x1d, 0x48b28, 0x14), at 0xffffffffffffffff [2] XPath::executeMore(0xffbee148, 0xffbee638, 0x75c54, 0x1d, 0x48b28, 0x9), at 0xff2185f4 [3] XPath::equals(0xffbee23c, 0xffbee638, 0x75c54, 0x12, 0x48b28, 0x0), at 0xff219154 [4] XPath::executeMore(0xffbee23c, 0xffbee638, 0x75c54, 0x12, 0x48b28, 0x8), at 0xff218454 [5] XPath::predicates(0xffbee638, 0x48b28, 0x75bfc, 0x10, 0x294a0, 0xffbee308), at 0xff21cbcc [6] XPath::step(0xffbee638, 0x48b28, 0x75bfc, 0x294a0, 0x29440, 0x1a), at 0xff21a5d8 [7] XPath::step(0xffbee638, 0x48b28, 0x75bd0, 0x72df8, 0x29480, 0x1), at 0xff21a678 [8] XPath::locationPath(0xffbee55c, 0xffbee638, 0x48b28, 0x75bd0, 0x2, 0x2), at 0xff21a1d0 [9] XPath::executeMore(0xffbee55c, 0xffbee638, 0x75bd0, 0x2, 0x48b28, 0x4), at 0xff2186d4 [10] XPath::executeMore(0xffbee55c, 0xffbee638, 0x75bd0, 0x0, 0x48b28, 0xff34b224), at 0xff2183b4 [11] XPath::execute(0xffbee55c, 0xffbee638, 0x75bd0, 0xffbee704, 0x48b28, 0x48b28), at 0xff218228 [12] XPathEvaluator::evaluate(0xffbee824, 0xffbee94c, 0xffbee940, 0x75bd0, 0xffbee638, 0xffbee704), at 0xff221f78 [13] XPathEvaluator::evaluate(0xffbee824, 0xffbee94c, 0xffbee940, 0x75bd0, 0x79940, 0xffbee704), at 0xff221eb8 [14] XPathEvaluator::evaluate(0xffbee824, 0xffbee94c, 0xffbee940, 0x75bd0, 0x79940, 0x75bd0), at 0xff221b40 =>[15] applyXPath(xmlFile = 0xffbef796 "t.xml", testFile = 0xffbef79c "t.dat"), line 111 in "XPathTest.cpp" [16] main(argc = 3, argv = 0xffbef63c), line 155 in "XPathTest.cpp" (dbx) >From tracing through a nightly build version of Xalan 1.4 built in conjunction with stlport, it looks like the equity test is where the problem manifests itself: (dbx) where [1] __sigprocmask(0x0, 0xffbed288, 0x0, 0x0, 0x0, 0x0), at 0xfe4d9790 [2] _resetsig(0xfe4dbf68, 0x0, 0x0, 0x6dcd8, 0xfe4ee000, 0x0), at 0xfe4ce9ac [3] _sigon(0x6dcd8, 0xfe4f5938, 0x6, 0xffbed35c, 0x6dcd8, 0xfe4d0f14), at 0xfe4ce14c [4] _thrp_kill(0x0, 0x1, 0x6, 0xfe4ee000, 0x1, 0xff1cb738), at 0xfe4d118c [5] raise(0x6, 0x0, 0x0, 0xffffffff, 0xff23e3cc, 0xff1b59c8), at 0xff1cb738 [6] abort(0xff23a004, 0xffbed4b0, 0x6d, 0x7efefeff, 0x81010100, 0xff00), at 0xff1b5aac [7] __assert(0xff06f0c9, 0xff06f0f6, 0x30b, 0xff06f0f6, 0x74ce0, 0xff00), at 0xff1b5d50 [8] XalanDOMString::invariants(this = 0x74e40), line 779 in "XalanDOMString.hpp" [9] XalanDOMString::assign(this = 0x74e40, theSource = CLASS), line 461 in "XalanDOMString.hpp" [10] XalanDOMString::operator=(this = 0x74e40, theRHS = CLASS), line 147 in "XalanDOMString.hpp" [11] XString::set(this = 0x74e18, theString = CLASS), line 97 in "XString.hpp" [12] XObjectFactoryDefault::createString(this = 0x74bd8, theValue = CLASS), line 405 in "XObjectFactoryDefault.cpp" [13] XPath::literal(this = 0xffbee274, _ARG3 = 0xa2054, opPos = 29, executionContext = CLASS), line 1010 in "XPath.cpp" [14] XPath::executeMore(this = 0xffbee274, context = 0xa2054, opPos = 29, executionContext = CLASS), line 245 in "XPath.cpp" [15] XPath::equals(this = 0xffbee274, context = 0xa2054, opPos = 29, executionContext = CLASS), line 721 in "XPath.cpp" [16] XPath::executeMore(this = 0xffbee274, context = 0xa2054, opPos = 18, executionContext = CLASS), line 193 in "XPath.cpp" [17] XPath::predicate(this = 0xffbee274, context = 0xa2054, opPos = 16, executionContext = CLASS), line 374 in "XPath.hpp" [18] XPath::predicates(this = 0xffbee274, executionContext = CLASS, _ARG3 = 0xa1ffc, opPos = 16, subQueryResults = CLASS, endPredicatesPos = 16), line 3102 in "XPath.cpp" [19] XPath::step(this = 0xffbee274, executionContext = CLASS, context = 0xa1ffc, opPos = 16, queryResults = CLASS), line 1351 in "XPath.cpp" [20] XPath::step(this = 0xffbee274, executionContext = CLASS, context = 0xa1fd0, opPos = 10, queryResults = CLASS), line 1372 in "XPath.cpp" [21] XPath::locationPath(this = 0xffbee274, executionContext = CLASS, context = CLASS, opPos = 2), line 1220 in "XPath.cpp" [22] XPath::locationPath(this = 0xffbee274, context = 0xa1fd0, opPos = 2, executionContext = CLASS), line 1062 in "XPath.cpp" [23] XPath::executeMore(this = 0xffbee274, context = 0xa1fd0, opPos = 2, executionContext = CLASS), line 273 in "XPath.cpp" [24] XPath::executeMore(this = 0xffbee274, context = 0xa1fd0, opPos = 0, executionContext = CLASS), line 173 in "XPath.cpp" [25] XPath::execute(this = 0xffbee274, context = 0xa1fd0, prefixResolver = CLASS, executionContext = CLASS), line 159 in "XPath.cpp" [26] XPathEvaluator::evaluate(this = 0xffbee50c, domSupport = CLASS, contextNode = 0xa1fd0, xpath = CLASS, prefixResolver = CLASS, envSupport = CLASS), line 459 in "XPathEvaluator.cpp" [27] XPathEvaluator::evaluate(this = 0xffbee50c, domSupport = CLASS, contextNode = 0xa1fd0, xpathString = 0x70270, prefixResolver = CLASS, envSupport = CLASS), line 433 in "XPathEvaluator.cpp" [28] XPathEvaluator::evaluate(this = 0xffbee50c, domSupport = CLASS, contextNode = 0xa1fd0, xpathString = 0x70270, namespaceNode = 0xa1fd0), line 290 in "XPathEvaluator.cpp" [29] applyXPath(xmlFile = 0xffbef455 "xml/t.xml", testFile = 0xffbef45f "t.dat"), line 484 in "XPathTest.cpp" [30] main(argc = 3, argv = 0xffbef2bc), line 552 in "XPathTest.cpp" (dbx) Near as I can tell it is failing this test: assert(m_data.empty() == true || m_data.back() == 0); Has anyone else seen this behavior? Am I missing something? Thanks! I don't see a place to attach reproducible cases - where should I email the example?
