Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1072 Incorrect optimization of name()='x' under Saxon-EE

v9.2
closed
Michael Kay
5
2012-10-08
2010-06-07
Michael Kay
No

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.

Discussion

  • Michael Kay
    Michael Kay
    2010-06-07

    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.

     
  • Michael Kay
    Michael Kay
    2010-06-07

    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.

     
  • Michael Kay
    Michael Kay
    2010-08-09

    Fixed in 9.2.1.2

     
  • Michael Kay
    Michael Kay
    2010-08-27

    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.

     
  • Michael Kay
    Michael Kay
    2010-12-01

    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.