Sorry, I'm back with this issue again. After some research, it actually turns out that the version in question which crashes at our customer site is Xalan 1.1 and NOT Xalan 1.3. This is a much older version for which there aren't even any archives kept at the Apache site anymore. I'm looking at http://xml.apache.org/dist/xalan-c/archives/ Unlike, the Xerces-C++ practice, Xalan-C++ seems to keep only the single previous release in it archives. Is it possible to get released versions older than 1.3 somehow?
After searching BugZilla for Xalan 1.1, I ran across http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2141 which talked about a problem with the way the Xalan library was built. This seems to go along with the mystery of why asserts are present in the release library we distributed, which looks like a build problem as well. If the old Xalan 1.1 is still archived somewhere, we would like to attempt a rebuild to fix the build problems. Also, in parallel we're looking into backporting an upgrade to the latest Xalan/Xerces for our old version of the product. It's probably a redundant question, but you would probably confirm that Xalan 1.4 would be a much more stable release than Xalan 1.1, correct? Thanks, - Chandu -----Original Message----- From: Chandu Bhavsar Sent: Friday, February 14, 2003 21:35 To: 'David N Bertoni/Cambridge/IBM' Subject: RE: Xalan 1.3 on Solaris crash Dave, Sorry about the HTML email. The Microsoft Outlook default format Rich Text got converted to HTML somehow. Thanks for your help. There were thousands of different XML inputs, and a single static XSL stylesheet run in a multi-threaded process when this crash occurred. I'm still trying to gather all the input docs. Your comment about presence of asserts in the release lib is interesting. I don't really know how this library was built, as I didn't personally build it. I will research on this, and in the worst case may need to rebuild it. Unfortunately, upgrading is not a trivial activity. We've moved to using Xalan 1.4 and Xerces 2.1 for our latest release. But for older releases (where this crash is seen), upgrades are almost out of question. This is due to complex dependency issues such as different Xerces, ICU versions etc. If I can come up with a standalone testcase that gives problem in Xalan 1.4 as well, I'll again post to the list/BugZilla. Thanks, - Chandu -----Original Message----- From: David N Bertoni/Cambridge/IBM [mailto:[EMAIL PROTECTED] Sent: Thursday, February 13, 2003 21:58 To: [email protected] Subject: Re: QuestionXalan 1.3 on Solaris crash Hi Chandu, Please don't post HTML to the mailing list -- it's a major pain for some of us to read. It's unlikely anyone can debug this without the input document(s) and stylesheet(s). The assert means the internal state of the processor is messed up, because the reference counting mechanism thinks the XObject instance has UINT_MAX reference counts (which is way too many). You can try to reproduce this with the latest version of Xalan. If you can't, the solution may be to upgrade, or to determine whether this was fixed incidentally, or there is an actual patch for it. If you can reproduce it with Xalan 1.4, then please file a bug report in Bugzilla and attach the document(s) and stylesheet(s) Another interesting question would be why the assert is even enabled. Did you ship a debug version of Xalan with your product? Or are you replicating on an in-house debug build? Although it's not ideal, many of these asserted conditions end up being harmless, because the processor resets things to a sensible state when it's finished. Dave > 7e441150 _thrp_kill (0, 19, 6, 7e45e000, 19, 7f440440) + f8 > 7f3cb94c raise (6, 0, 0, ffffffff, 7f4403ac, 0) + 40 > 7f3b58ec abort (7f43c000, 7457c848, 74, 7efefeff, 81010100, ff0000) + 100 > 7f3b5b90 _assert (6ffb94d8, 6ffb94fc, 6a, 6ffb94fc, 4ecd8b8, > 7457cb44) + 54 > 6fe3c858 void XalanReferenceCountedObject::removeReference(XalanReferenceCountedObject *) (7002970c, 6ffe3b68, 945e9c0, 6a96044, 5647b90, 4ecd8b8) + 74 > 6fefc228 void ElemIf::execute(StylesheetExecutionContext&,XalanNode*,XalanNode*,const QName&)const (7457cb1c, 7457cb0c, 7457cb08, 6ffe3b30, 7457ce14, 95ae0a8) + 158 > 6ff0aa78 void ElemTemplateElement::executeChildren(StylesheetExecutionContext&,XalanNo de*,XalanNode*,const QName&)const (6a96040, 4ecd8b8, 95ae0a8, 945e9c0, 7457ce14, 95ae0a8) + 54 ...
