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=22524>. 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=22524 Release-Build crashes on Sun if different compiler is used for client-code Summary: Release-Build crashes on Sun if different compiler is used for client-code Product: Xerces-C++ Version: 2.1.0 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Build AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I know this will be hard to reproduce and track down, but I want to report it nevertheless, to make sure other users of Xerces can avoid getting hit by this problem. We now had twice the situation that we compiled Xerces with one set of Solaris OS/Compiler and used the resulting binaries to compile our client-code with a similar, but not completely equal system. The resulting binaries seem to work ok, but in some special cases when running the release-binaries the application simply crashes inside Xerces. Debug-Mode is never a problem, which makes diagnosing this even harder. Recompiling Xerces on the same OS/Compiler combination as the client-code fixes the problem! We had this problem over a year ago when we compiled Xerces on Solaris 7 and later switched to Solaris 8 without recompiling Xerces and now we had the same problem again when the Xerces binary was compiled with different Compiler-Versions: Xerces was compiled with: $ CC -V CC: Sun WorkShop 6 update 1 C++ 5.2 2000/09/11 and the client-code was compiled with $ CC -V CC: Sun WorkShop 6 update 1 C++ 5.2 Patch 109508-09 2002/07/08 This means that even a patch to the Compiler caused this problem. A sample stack-trace is shown below: [EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal BUS (invalid address alignment) (/opt/SUNWspro/bin/../WS6U1/bin/sparcv9/dbx) where current thread: [EMAIL PROTECTED] =>[1] ReaderMgr::reset(0xfc342, 0x7, 0xfea2beb8, 0x1172e0, 0x0, 0x0), at 0xfe8cfb84 [2] XMLScanner::scanDocument(0xfce38, 0xa3ae0, 0xfeeea880, 0xfeed6c04, 0xfe8b6ed4, 0x0), at 0xfe91dfb0 [3] AbstractDOMParser::parse(0xffbee930, 0xa3ae0, 0xfeeea054, 0x48f68, 0x0, 0x0), at 0xfe8528a4 [4] XMLScanner::resolveSchemaGrammar(0xffbee930, 0x0, 0x8d298, 0xffbee9e7, 0xfe99cf0c, 0x13), at 0xfe9283a8 [5] XMLScanner::parseSchemaLocation(0xa5e00, 0x83f00, 0x0, 0xfeeea5e8, 0xdd6ca, 0xfea2bc60), at 0xfe9280e0 [6] XMLScanner::scanRawAttrListforNameSpaces(0xffbeea4c, 0x83f00, 0xfea166ce, 0xfea16720, 0x5, 0xfea2b65e), at 0xfe927e44 [7] XMLScanner::scanStartTagNS(0xa5e4c, 0x1, 0x1, 0x0, 0xfe9b1b48, 0xfe92b8b0), at 0xfe922da0 [8] XMLScanner::scanContent(0xa5e00, 0x0, 0xfea2b634, 0xfea2b65c, 0xff3e2628, 0xfe5f6890), at 0xfe920110 [9] XMLScanner::scanDocument(0xa5e00, 0xd6c80, 0xfeed5568, 0xfeeea5e8, 0xff3e2628, 0xfeb441e7), at 0xfe91dcc4 [10] SAX2XMLReaderImpl::parse(0xa5cf8, 0xd6c80, 0x1ac7, 0x776b0, 0x0, 0xfeb4336a), at 0xfe8db11c [11] CFTIXMLHierFormatParser::Parse(0xd6c80, 0x7b860, 0x0, 0x39e38, 0xffbeedec, 0x0), at 0xfe60cd98 In the case of the stack-trace above, we were trying to parse an XML-File that contained an invalid XSD-Schema-URL to do validation. The parsing was stopped and during error-handling the crash occurred. I know that this may also be a problem of Solaris or the Workshop Compiler itself, but we use a bunch of other libraries (Xalan, regexpp, JScript, ...) and none of them crashes like Xerces. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
