Bug #1060
closed
Variable in key() within xsl:number/@count causes exception
0%
Description
SourceForge user: svanteschubert
During using a key function in the xsl:number element's count attribute with a parameter given variable, Saxon throws an exception (attached).
In the latest version the message is:"java.lang.ArrayIndexOutOfBoundsException: Local variable has not been allocated a stack frame slot".
<xsl:key name="listItemsLevel1" use="parent::text:list/@text:style-name" match="text:list/*"/>
...
<xsl:param name="listStyleName"/>
...
<xsl:number level="any"
from="/*/office:body"
count="key('listItemsLevel1', $listStyleName)"/>
If the used variable is created before xsl:number there is no problem, nevertheless $listStyleName is always given as string and never null or empty.
Please find my test scenario in the attached ZIP. As Saxon is build on Windows, I included a batch file (testscenario\test.bat) to trigger the XSL transformation (ODF to XHTML).
The problem occurs in testscenario\xslt\export\xhtml\body.xsl line 1070.
For the background:
What I am counting in an ODF are text:list-item all preceding text:list-items with the same level (=similar amount of text:list parents) and same text:list style (=style of a ancestor text:list) to create the numbering label.
In ODF even separated text:list have a continuous numbering, as long the text:list has the same style.
Files
Updated by Anonymous almost 16 years ago
SourceForge user: svanteschubert
Logged In: YES
user_id=2146577
Originator: YES
File Added: exception-9-1-0-1j.txt
Updated by Anonymous almost 16 years ago
SourceForge user: svanteschubert
Logged In: YES
user_id=2146577
Originator: YES
File Added: exception-9-0-0-xj.txt
Updated by Anonymous almost 16 years ago
SourceForge user: mhkay
Logged In: YES
user_id=251681
Originator: NO
There are actually a number of separate problems in this area:
(a) it affects variables used in both the key() and id() patterns
(b) the variable has no slot allocated if the pattern is used in and instruction (xsl:number or xsl:for-each-group), and also if it is used in a step other than the last in a top-level pattern (xsl:template or xsl:key match patterns)
(c) this is really a quite separate problem, but is being fixed at the same time: the value of the variable is not atomized, which means that a ClassCastException occurs if its value is a node.
Patches to the affected modules will be raised in Subversion in both the 9.0 and 9.1 branches.
Updated by Anonymous almost 16 years ago
SourceForge user: mhkay
Logged In: YES
user_id=251681
Originator: NO
I've created some additional tests to stress the use of current() and variable references in various positions within patterns, and found a few more obscure cases that weren't being handled. In fact I could only provoke the failures on 9.0, but the incorrect code is also present in 9.1, so I'm applying patches to both branches in Subversion. The problem cases include (a) use of a variable in a key() or id() pattern that forms one branch of a union pattern, (b) use of a variable in a key() or id() pattern within an xsl:number or xsl:for-each-group instruction in a context where the variable can be evaluated or inlined at compile time.
Updated by Anonymous over 15 years ago
SourceForge user: mhkay
Logged In: YES
user_id=251681
Originator: NO
Fixed in 9.0.0.8 and 9.1.0.2
(Omitted from the 9.0.0.8 change log, however)
Please register to edit this issue
.