Bug #2008
closed
Problem using xsl:copy-of with an xsl:variable
Fixed in Maintenance Release:
Description
The problem occurs in some very specific conditions, so I made an example project to illustrate it, that I'm attaching to this ticket.
The problem appears when :
-
you run a transformation that opens a large file with document()
-
run a second transformation (even if unrelated) that puts some data in an xsl:variable and use xsl:copy-of on that variable
One thing about this bug that my example doesn't illustrate :
- only some parts of the variable aren't copied, if you make an xml structure in the variable and fill it with data from different places in the source document, only the first field of data inserted with xsl:value-of will be omitted, the structure and the following data will be there.
To run the example project use @mvn test@, it will generate a large file in the project root dir, then run a transformation on that file (without any output), then run a transformation that makes a variable and a copy of it, and display the (incorrect) result. Then it will run that exact transformation again, displaying the result again, which is (for some reason) correct.
Files
I forgot to mention, the problem is present in all 9.5 releases, but not in any 9.4.
- Category set to Internals
- Status changed from New to In Progress
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Found in version set to 9.5
Thanks for reporting this and pinning it down so precisely.
I've reproduced the problem and have worked out the rough cause. It's to do with the TiInyTree statistics, which are kept in static data. The statistics are used when allocating space to a new tree; the space allocated initially is based on how large previous constructed trees in the VM have been, on the basis that there is often some uniformity. Your initial large transformation sets the statistics high, and this is causing the second tree to be allocated very large. For some reason (which I now need to investigate) when a small tree is built in this large space, data gets lost. On the third run, the statistics have adjusted and the tree is created with a more reasonable size, so the problem does not occur.
Incidentally there is an opportunity for optimization here which Saxon misses. Saxon inlines the variable because there is only one reference to it, but it fails to spot that the copy-of operation is therefore redundant; it could avoid building the temporary TinyTree entirely.
Incidentally, my initial assumption was that the problem was something to do with reading or writing the DOM, since the DOM paths are so tortuous in Saxon. However, this appears not to be the case.
The error is in the code that copies text from a StringBuffer (as produced by the DOM wrapper code) to a Saxon LargeStringBuffer (as used on the TinyTree when the expected amount of text exceeds 65535 characters). Saxon does not normally use the StringBuffer class, and the LargeStringBuffer class is handling this case incorrectly. So the fact that a DOMSource is used is in fact relevant to the problem.
- Status changed from In Progress to Resolved
A patch has been applied and tested in class LargeStringBuffer. This will appear in the next maintenance release. Fixed on the 9.5 and 9.6 branches.
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in version set to 9.5.1.5
Bug fix applied in Saxon maintenance release 9.5.1.5
Please register to edit this issue
Also available in: Atom
PDF
.