Saxon

The cause looks pretty clear from the stack trace: StringTool#277 is calling CompressedWhitespace.compressWS(in, offset, end); but the method declaration is public static UnicodeString compressWS(char[] in, int start, int len) so we're clearly passing an "end" offset where a length is expected.

Which obviously raises questions like (a) why is it only happening on this path, and (b) how can we write a regression test to catch the failure and make sure it's fixed.

(This confusion between end offset and length is a real elephant trap. Both conventions are widely used in Java APIs).

The reason the problem doesn't arise when a push parser is used is that on that path we only compress whitespace after assembling multiple text fragments in a buffer, and as a result it always calls compress() with a start offset of 0, in which case end and length are interchangeable.

As for testing, we only run a rather small number of tests with a pull parser. I'll take a close look at some of those tests to see what path they are taking.

The tests we are running use Woodstox, which does indeed supply text in a 4000-character buffer -- but like the SAX parser, it's always returning 0 as the result of reader.getTextStart(), which means we're again setting start=0 and therefore not seeing any distinction between end and length.

I think the best way of tackling this is going to be to write a unit test that invokes the compression methods directly, rather than trying to trigger an XML parser to set the right input conditions.