Bug #4459

ArrayIndexOutOfBoundsException at net.sf.saxon.serialize.HTMLIndenter.comment

Added by T Hata over 1 year ago. Updated over 1 year ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:


The attached files lead to this exception:

C:\test>java -jar saxon9ee.jar -s:test.xml -t -xsl:test.xsl
Saxon-EE from Saxonica
java.lang.ArrayIndexOutOfBoundsException: 20
        at net.sf.saxon.serialize.HTMLIndenter.comment(
        at net.sf.saxon.event.ProxyReceiver.comment(
        at net.sf.saxon.event.ProxyReceiver.comment(
        at net.sf.saxon.event.ProxyReceiver.comment(
        at net.sf.saxon.event.SequenceNormalizer.comment(
        at net.sf.saxon.event.ProxyReceiver.comment(
        at net.sf.saxon.event.ComplexContentOutputter.comment(
        at net.sf.saxon.tree.tiny.TinyElementImpl.copy(
        at net.sf.saxon.tree.tiny.TinyDocumentImpl.lambda$copy$0(
        at net.sf.saxon.tree.tiny.TinyDocumentImpl.copy(
        at net.sf.saxon.trans.rules.DeepCopyRuleSet.process(
        at net.sf.saxon.trans.Mode.applyTemplates(
        at net.sf.saxon.trans.XsltController.applyTemplates(
        at net.sf.saxon.s9api.AbstractXsltTransformer.applyTemplatesToSource(
        at net.sf.saxon.s9api.Xslt30Transformer.applyTemplates(
        at net.sf.saxon.Transform.processFile(
        at net.sf.saxon.Transform.doTransform(
        at net.sf.saxon.Transform.main(
Fatal error during transformation: java.lang.ArrayIndexOutOfBoundsException: 20 (559 Bytes) T Hata, 2020-02-17 10:38


#1 Updated by Michael Kay over 1 year ago

Thank you, problem reproduced. The problem occurs when doing serialization with method="html", indent="yes", and a comment appears as the content of an element at depth 20 (or 20*2^n for some n).

Saxon is using the classic technique of using an int array with manual doubling of the size when it fills, rather than using a Java Stack (and it's failing to check for the array being full on this particular path). I suspect that in prehistoric times there was a performance justification for this (it's a stack of integers, so we avoid the cost of boxing and unboxing), but I rather doubt whether that is true in modern Java releases, and it's probably not a performance-critical path anyway. So the right solution is probably to use a Java Stack<Integer> here.

But that's not the actual issue: the code for outputting comments and PIs is trying to establish whether it's within an inline element by looking at the element properties at level L, when the enclosing element is actually at level L-1. Since properties aren't removed from the stack on endElement(), this is actually looking at whether the last element actually at level L (perhaps a preceding sibling, perhaps a preceding cousin) was an inline element. So perhaps a simpler fix is just to add the "-1".

#2 Updated by Michael Kay over 1 year ago

Changing it to access propertyStack[level-1]. But we also need a check for level != 0 to avoid crashing on document-level comments and PIs.

#3 Updated by Michael Kay over 1 year ago

  • Category set to Serialization
  • Status changed from New to Resolved
  • Assignee set to Michael Kay
  • Priority changed from Low to Normal
  • Applies to branch 9.9, trunk added
  • Fix Committed on Branch 9.9, trunk added

Fixed by changing the code for comment() and processingInstruction() to access propertyStack[level-1] with a check for level==0. Can leave changing the stack implementation to another day.

#4 Updated by O'Neil Delpratt over 1 year ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release added

Patch applied in the maintenance release.

Please register to edit this issue

Also available in: Atom PDF