Project

Profile

Help

Bug #2567

closed

java.lang.NullPointerException with external variable in xsl:iterate/on-completion

Added by David Rudel almost 9 years ago. Updated over 8 years ago.

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

100%

Estimated time:
Legacy ID:
Applies to branch:
9.6, 9.7
Fix Committed on Branch:
9.6, 9.7
Fixed in Maintenance Release:
Platforms:

Description

The attached template throws a java.lang.NullPointerException.

It appears the problem is the on-completion element using a variable from outside the xsl:iterate scope.


Files

Iteration_Null_pointer_error.xsl (737 Bytes) Iteration_Null_pointer_error.xsl David Rudel, 2015-12-31 13:19
Actions #1

Updated by Michael Kay almost 9 years ago

  • Subject changed from java.lang.NullPointerException with external variable in on-completion to java.lang.NullPointerException with external variable in xsl:iterate/on-completion
  • Status changed from New to In Progress
  • Priority changed from Low to Normal
  • Applies to branch 9.6, 9.7 added

Reproduced in 9.6.0.8:

Saxon-EE 9.6.0.8J from Saxonica

Java version 1.6.0_27

Using license serial number xxxxxx

java.lang.NullPointerException

at net.sf.saxon.expr.AxisExpression.computeCardinality(AxisExpression.java:748)

at net.sf.saxon.expr.Expression.computeStaticProperties(Expression.java:876)

at net.sf.saxon.expr.Expression.getSpecialProperties(Expression.java:279)

at net.sf.saxon.expr.FilterExpression.optimize(FilterExpression.java:458)

Under 9.7 we get a different problem:

Saxon-EE 9.7.0.1J from Saxonica

Java version 1.6.0_27

Using license serial number xxxxxx

Static error at char 3 in xsl:variable/@select on line 8 column 55 of iterate_throws_npe.xsl:

XPDY0002: Axis step child::element(Q{}day) cannot be used here: the context item is absent

Generating byte code...

Cannot compile /(null) - using interpreter

Warning: Bytecode generation failed for /: null

Errors were reported during stylesheet compilation

Actions #2

Updated by Michael Kay almost 9 years ago

The problem seems to be that the variable reference $last.day is being inlined - that is, we rewrite xsl:on-completion select="$last.day" as xsl:on-completion select="day[last()]", and this rewrite is incorrect because the focus for evaluating the xsl:on-completion is not the same as the focus for the variable declaration. The NPE occurs because we have constructed a focus-dependent expression in a context where there is no focus.

Actions #3

Updated by Michael Kay almost 9 years ago

  • Fix Committed on Branch 9.6, 9.7 added

Fixed on both the 9.6 and 9.7 branches (by preventing the variable being inlined). Although the symptoms differ, the root cause is the same in both releases.

Test case currently in file:/Users/mike/bugs/2015/rudel/iterate_throws_npe.xsl; leaving the bug "in progress" until a regression test is integrated.

Actions #4

Updated by Michael Kay almost 9 years ago

The change has had a side-effect which causes a number of streaming tests to fail, for example sf-boolean-100.

This test executes

<xsl:template name="c-100" use-when="true() or $RUN">

  <xsl:variable name="b" select="current-date() gt xs:date('1900-01-01')"/>

  <xsl:stream href="../docs/big-transactions.xml">

    <out>

      <xsl:value-of select="boolean(($b, account/transaction/dummy))"/>

    </out>

  </xsl:stream>

</xsl:template>

Previously variable $b was being inlined, and then the streamability analysis was performed.

Now $b is not inlined. The streamability analysis is OK, but then further optimization is carried out, and this causes the expression (current-date() gt xs:date('1900-01-01')) to be bound to a global variable; a global variable reference appears within the xsl:stream, and at run-time a failure occurs because this new expression has not been analyzed for streamability.

  1. I think we should modify the patch so that inlining does happen in this case.

  2. But this still leaves a design problem: we should really not change the tree after doing the inversion, otherwise we are going to hit this kind of problem.

I have fixed (1) by ensuring that the new rule inhibiting variable inlining when the focus changes applies only if the expression is focus-dependent.

As for (2), I'm just going to put a comment in the code noting the problem for now.

Actions #5

Updated by Michael Kay almost 9 years ago

  • Status changed from In Progress to Resolved
Actions #6

Updated by O'Neil Delpratt almost 9 years ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.7.0.2 added

Bug fix applied in the Saxon 9.7.0.2 maintenance release

Actions #7

Updated by O'Neil Delpratt almost 9 years ago

  • Fixed in Maintenance Release 9.7.0.3 added
  • Fixed in Maintenance Release deleted (9.7.0.2)

Bug fix applied in the 9.7.0.3 maintenance release. Leave open until fix applied in the 9.6 branch

Actions #8

Updated by O'Neil Delpratt over 8 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.6.0.9 added
  • Fixed in Maintenance Release deleted (9.7.0.3)

Bug fix applied in the Saxon 9.6.0.9 maintenance release.

Actions #9

Updated by O'Neil Delpratt over 8 years ago

  • Fixed in Maintenance Release 9.7.0.3 added
Actions #10

Updated by O'Neil Delpratt over 8 years ago

  • Sprint/Milestone set to 9.7.0.3

Please register to edit this issue

Also available in: Atom PDF