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=5767>. 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=5767 xerces-C crashes on a multiprocessor machine running Solaris 5.7 Summary: xerces-C crashes on a multiprocessor machine running Solaris 5.7 Product: Xerces-C++ Version: 1.5.2 Platform: Sun OS/Version: Solaris Status: NEW Severity: Critical Priority: Other Component: Non-Validating Parser AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Used gcc/g++ compiler version 2.8.1 to compile both Xerces library as well as the test programs. Till recently we built and ran our multi-threaded processes that use Xerces-C library on a single-processor SPARC machines that run Solaris 2.7. In that environment we never had a problem with multiple threads running separate instances of DOM parser. Since we switched to a multiprocessor machine ( 8 CPUs) [SunOS mldevapps2 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-Enterprise] xerces crashes often. We were able to reproduce the crashes with our own test programs as well as with the ThreadTest program included in Xcerces distribution. All versions of Xerces that we tested (i.e. 1.1, 1.3, 1.4 and 1.5.2) crash under the same circumstaces. Xerces crashes when multiple threads parse XML simultaneously each using its own instance of a DOM parser object. Here is a snippet of code from our test program that each thread executes: ........... ........... ........... void* parseXml (void* arg) { DOMParser parser; ParseErrorReporter errReporter; string xmlBuffer; fileToString (gFilename, xmlBuffer); MemBufInputSource memBuf ((const XMLByte*)xmlBuffer.c_str(), xmlBuffer.size(), "ma1stepapi", false); parser.setErrorHandler (&errReporter); parser.setDoValidation (gDoValidation); try { cerr << "parsing..."; parser.parse (memBuf); cerr << "done\n"; } catch (const XMLException& e){ string error = (const char*)e.getMessage(); cerr << "Parsing error: " << endl << error << endl; return 0; } return 0; } ...... ...... ...... The test programs CRASH ONLY WHEN AN EXTERNAL DTD IS SPECIFIED. As long DTD is included inside of the XML file or is not specified at all the test programs never crash. Here is what a stack trace looks like in a typical crash for version 1.3 of Xerces: #0 0xff046424 in _free_unlocked () from /usr/lib/libc.so.1 #1 0xff0463dc in free () from /usr/lib/libc.so.1 #2 0xff154d10 in ___builtin_delete (ptr=0x2) from /usr/local/lib/libstdc++.so.2.8.1 #3 0xff154d90 in ___builtin_vec_delete (ptr=0x2) from /usr/local/lib/libstdc++.so.2.8.1 #4 0xff2943d4 in XMLURL::cleanup (this=0xfe9097c8) at XMLURL.cpp:681 #5 0xff2932e0 in XMLURL::~XMLURL (this=0xfe9097c8, __in_chrg=2) at XMLURL.cpp:360 #6 0xff293928 in XMLURL::setURL (this=0x1, baseURL=0x2e970, relativeURL=0x2) at XMLURL.cpp:464 #7 0xff258560 in ReaderMgr::getSpaces (this=0x419f8, toFill=@0x2e970) at ReaderMgr.cpp:164 #8 0xff21a23c in DTDValidator::scanExtSubsetDecl (this=0x97f90, inIncludeSect=false) at DTDValidator2.cpp:2527 #9 0xff216668 in DTDValidator::scanDocTypeDecl (this=0x97f90, reuseValidator=false) at DTDValidator2.cpp:1680 #10 0xff210970 in DTDValidator::scanDTD (this=0x97f90, reuseValidator=false) at DTDValidator.cpp:774 #11 0xff285fa0 in XMLScanner::scanProlog (this=0x41988) at XMLScanner.cpp:1885 #12 0xff27fea0 in XMLScanner::scanDocument (this=0x41988, src=@0xfe909cd8, reuseValidator=false) at XMLScanner.cpp:284 #13 0xff1f7ec0 in DOMParser::parse (this=0xfe909d08, source=@0xfe909cd8, reuseValidator=false) at DOMParser.cpp:253 #14 0x15c18 in parseXml () --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
