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&,XalanNode*,XalanNode*,const
QName&)const (6a96040, 4ecd8b8, 95ae0a8, 945e9c0, 7457ce14, 95ae0a8) + 54
...
