Project

Profile

Help

Bug #1060

closed

Variable in key() within xsl:number/@count causes exception

Added by Anonymous over 16 years ago. Updated over 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Legacy ID:
sf-2017808
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

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

testscenario.zip (9.56 KB) testscenario.zip Anonymous, 2008-07-14 09:26
exception-9-1-0-1j.txt (9.56 KB) exception-9-1-0-1j.txt Anonymous, 2008-07-14 09:27
exception-9-0-0-xj.txt (9.56 KB) exception-9-0-0-xj.txt Anonymous, 2008-07-14 09:28
Actions #1

Updated by Anonymous over 16 years ago

SourceForge user: svanteschubert

Logged In: YES

user_id=2146577

Originator: YES

File Added: exception-9-1-0-1j.txt

Actions #2

Updated by Anonymous over 16 years ago

SourceForge user: svanteschubert

Logged In: YES

user_id=2146577

Originator: YES

File Added: exception-9-0-0-xj.txt

Actions #3

Updated by Anonymous over 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.

Actions #4

Updated by Anonymous over 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.

Actions #5

Updated by Anonymous about 16 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

Also available in: Atom PDF