Bug #896
closed*** Internal Saxon error: Unbound local variable encountered
0%
Description
SourceForge user: jessholle
I assume based on the term "Internal Saxon error", that this is a bug in Saxon's diagnostics if nothing else. I further suspect that it is a straight-out bug in Saxon 8.9 as the XSLT in question worked in Saxon 8.8 (and worked largely unchanged since Saxon 6.x days prior to that).
I would appreciate resolution of this issue (e.g. a patch or new Saxon version) or an ETA for such a resolution as this currently is keeping me from upgrading to Saxon 8.9, which I'd otherwise love to do.
Files
Updated by Anonymous over 17 years ago
SourceForge user: jessholle
Logged In: YES
user_id=883982
Originator: YES
I am also attaching the XSLT in which the variable in question resides and the XSLT which xsl:include's it.
File Added: htmlWithSortingBase.xsl
Updated by Anonymous over 17 years ago
SourceForge user: jessholle
Logged In: YES
user_id=883982
Originator: YES
File Added: htmlWithSorting.xsl
Updated by Anonymous over 17 years ago
SourceForge user: jessholle
Logged In: YES
user_id=883982
Originator: YES
Please let me know if further details are required.
Updated by Anonymous over 17 years ago
SourceForge user: mhkay
Logged In: YES
user_id=251681
Originator: NO
I managed to reproduce this despite the fact that several of the files were missing.
The problem is in the code for inlining of variables. If the only reference to a variable is in the order attribute of xsl:sort, inlining is attempted but leaves the expression tree in an inconsistent state. A patch is in Subversion. As a circumvention, the simplest thing is to move the expression inline:
order="{if ($sortIsDescending='true') then 'descending' else 'ascending'}"
Please note: I ask people not to enter bug reports directly into this tracker, but rather to report problems via the saxon-help list or forum, or the support-requests tracker. There are several reasons for this. One is to avoid this list becoming cluttered with things that turn out not to be bugs at all; another is so that people searching the list get straight to a description of the actual bug, without wading through lots of chat while it was being diagnosed. Another reason is simply that I don't get notified of entries on this list unless they are explicitly assigned to me: I spotted this one purely by chance.
Updated by Anonymous over 17 years ago
SourceForge user: jessholle
Logged In: YES
user_id=883982
Originator: YES
Thanks for spotting this issue, the fix, and the kindly note. I was unaware of the "forum first" policy and will do my best to follow that policy in the future.
Excuse my ignorance, but how might I find the patch in subversion? [I really want a fix rather than a workaround purely because I don't know where else we or our customers might use patterns that run afoul of this bug.]
Updated by Anonymous over 17 years ago
SourceForge user: jessholle
Logged In: YES
user_id=883982
Originator: YES
Ah... I believe the only necessary file for this patch is SortExpression.java. Correct? If so, then I guess I have the patch.
Updated by Anonymous over 17 years ago
SourceForge user: mhkay
Logged In: YES
user_id=251681
Originator: NO
Yes. I usually try to include the name of the affected module within the bug description to make it easier to find in Subversion but on this occasion I forgot. The Subversion log for the module always contains a reference to the bug number.
Updated by Anonymous over 17 years ago
SourceForge user: mhkay
Logged In: YES
user_id=251681
Originator: NO
Fixed in 8.9.0.3
Please register to edit this issue