Bug #144
closed
Incorrect optimization of name()='x' under Saxon-EE
0%
Description
SourceForge user: mhkay
Under Saxon-EE, if the zero-argument function name() (or similar functions such as local-name()) is called within an operand of "=", that is, in an expression such as name()='abc' or substring(name(), 1,1) = 'a', the optimizer may work on the incorrect assumption that the expression is not dependent on the context item, which may cause it to be moved out of a loop, function, or template, which in turn will cause the name() function to be evaluated against the wrong node, typically causing the "=" comparison to return false.
A patch (to module OptimizerEE in the Saxonica-private code) is being committed.
Updated by Anonymous over 14 years ago
SourceForge user: mhkay
Further investigation shows that the problem is present in 9.1.0.8 as well, however no patch is being raised on that branch at present in the interests of code stability.
Although the problem sounds serious, the circumstances in which it occurs seem to be rather limited. So far it has only been demonstrated with a construct of the form substring(name(), m, n_ = 'xyz', although the incorrect code is certainly activated on other paths as well.
Updated by Anonymous over 14 years ago
SourceForge user: mhkay
The design of the patch has been changed; it now affects the Saxon-HE open source code, modules GeneralComparison, GeneralComparison10, Optimizer, and ExpressionParser, as well as Saxonica private code.
Updated by Anonymous about 14 years ago
SourceForge user: mhkay
Unfortunately the patch (as issued in 9.2.1.2) is incorrect or incomplete. With stylesheets running in XSLT 1.0 mode (such as the docbook stylesheets) it can cause a NullPointerException at
net.sf.saxon.expr.GeneralComparison10.compare(GeneralComparison10.java:324). A further patch is being raised to prevent this - though it doesn't really address the root cause, which is a late change being made by the optimizer to create an expression class that expects to be revisited later in the process.
Updated by Anonymous almost 14 years ago
SourceForge user: mhkay
A further occurrence of this problem has been found in 9.3 (and is also present in 9.2). In this case there is a filter expression $exp[name() = $value], and the predicate is being loop-lifted because the optimizer decides it is not dependent on the context item; it is then positioned immediately within a function body, where there is indeed no context item, and this is detected and reported as an error. The problem in this case is caused by the fact that the filter expression appears within the let clause of a FLWOR expression that performs sorting, and on this branch there is a very early type-check to determine the type of the sort key; this precomputes static properties of the expression (including whether or not it depends on the context item) before the simplify() method has been called to add the implicit argument ".". The immediate fix to this is to ensure that when simplify() is eventually called, the static properties are reset not just for the name() expression (as currently) but for all the ancestor expressions in the expression tree.
Please register to edit this issue
.