Bug #4251
closed
java.lang.NullPointerException in Saxon-EE 9.9.1.4J but not Saxon-PE 9.9.1.4J
100%
Description
I am getting a java.lang.NullPointerException only in Saxon-EE.
I will add a sample as soon as I can. I am posting the stack trace now in the hope that you have an 'Aha!' moment sooner than I can whittle everything down to a manageable size.
java.lang.NullPointerException
at net.sf.saxon.expr.VariableReference.computeCardinality(VariableReference.java:395)
at net.sf.saxon.expr.Expression.computeStaticProperties(Expression.java:1196)
at net.sf.saxon.expr.Expression.getDependencies(Expression.java:772)
at net.sf.saxon.expr.Expression.computeDependencies(Expression.java:1258)
at net.sf.saxon.expr.Expression.computeStaticProperties(Expression.java:1195)
at net.sf.saxon.expr.Expression.getCardinality(Expression.java:714)
at net.sf.saxon.expr.parser.TypeChecker.staticTypeCheck(TypeChecker.java:159)
at net.sf.saxon.expr.GeneralComparison.typeCheck(GeneralComparison.java:211)
at com.saxonica.ee.optim.IndexedFilterExpression.optimize(IndexedFilterExpression.java:185)
To this untrained eye, this looks similar to #2567
Unfortunately, the first and last stylesheet references in the stack trace are:
Caused by: java.lang.RuntimeException: Internal error evaluating template rule at line 98 in module file:/P:/tgraham/pubsrc/xsl/xxxxx2pdf/generateBookmarks.xsl
which is this template:
<xsl:template mode="make-bookmark-label" match="xhtml:header" as="xs:string?">
<xsl:param name="doDebug" as="xs:boolean" tunnel="yes" select="false()"/>
<xsl:variable name="content">
<xsl:apply-templates mode="#current">
<xsl:with-param name="doDebug" as="xs:boolean" tunnel="yes" select="$doDebug"/>
</xsl:apply-templates>
</xsl:variable>
<xsl:variable name="base-text">
<xsl:value-of select="$content"/>
</xsl:variable>
<xsl:sequence select="normalize-space($base-text)"/>
</xsl:template>
so I'm not expecting much joy until you can see a sample.
Files
Updated by Michael Kay almost 5 years ago
Thanks for reporting it. I'm afraid with internal errors like this, we usually need to be able to reproduce them in order to make any progress, so a complete stylesheet would be appreciated. It's worth seeing if the problem still occurs if JIT compilation of template rules is disabled (-opt:-j).
The stack trace gives a rough indication of what's going on: a filter expression such as $x[ppp = $y] has been optimised into an "indexed filter expression" and this is being typechecked, which is failing because there's a variable reference whose properties have not been fully initialized. But we need to find out why, and that can only be done by reproducing it. The fragment of the stylesheet you've shown us doesn't seem relevant because there's no filter expression involved.
Updated by Michael Kay almost 5 years ago
In fact it's on a slightly unusual path where the IndexedFilterExpression optimization is being reversed based on new information: the variable to which the predicate applies has been inlined, which makes it possible to make a more intelligent decision about whether indexing is appropriate. But it will still be hard to solve without a repro.
Updated by Michael Kay almost 5 years ago
I think I can see what's wrong with the code, and I might be prepared to hazard an untested patch, but it would be much better to have a repro that we can test it on. It's not easy to construct a test case that will take this path. I could try running the test suite to see whether any existing tests take this path but I suspect the answer will be that there aren't any, otherwise we would have seen the failure.
Updated by Tony Graham almost 5 years ago
I gave up hope on your 'Aha!' moment when I saw how dull the most significant template from the stack trace really was. I included it anyway, otherwise you would have asked for it.
Innumerable stack traces later...
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<header>
<h1/>
</header>
</html>
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:local="urn:ns:local-functions"
exclude-result-prefixes="#all"
expand-text="yes"
version="3.0">
<xsl:template
match="xhtml:header/xhtml:h1">
<xsl:variable name="class-value" select="string(@class)"/>
<xsl:variable name="subtitle-text" as="xs:string?"
select="normalize-space(following-sibling::*[local:hasDataTypeToken(., 'subtitle')])"
/>
<xsl:variable name="new-class"
select="if ($subtitle-text ne '')
then string-join(($class-value, 'has-subtitle'), ' ')
else $class-value"
/>
<xsl:copy>
<xsl:if test="$new-class ne ''">
<xsl:attribute name="class" select="$new-class"/>
</xsl:if>
</xsl:copy>
</xsl:template>
<!-- Return true if the specified element has any of the specified
tokens in its @data-type value.
-->
<xsl:function name="local:hasDataTypeToken" as="xs:boolean">
<xsl:param name="context" as="element()"/>
<xsl:param name="tokens" as="xs:string*"/>
<!-- <xsl:message select="exists($context/@data-type)" /> -->
<xsl:variable name="result" as="xs:boolean"
select="tokenize($context/@data-type, ' ') = ($tokens)"
/>
<xsl:sequence select="$result"/>
</xsl:function>
</xsl:stylesheet>
Updated by Michael Kay almost 5 years ago
Thanks. Problem now reproduced.
What's happening is that it does an indexing optimization for the many-to-many "=" comparison
tokenize($context/@data-type, ' ') = ($tokens)
and then reverses this optimization after it inlines the function and discovers that the value of $tokens is actually a singleton.
Nothing wrong with that in principle, but it turns out to be a path that hasn't been suitably exercised and the data on the reverse optimization isn't properly initialized.
Updated by Michael Kay almost 5 years ago
- Category set to XPath conformance
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 9.9, trunk added
- Fix Committed on Branch 9.9, trunk added
Updated by O'Neil Delpratt over 4 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.9.1.5 added
Bug fix applied in the Saxon 9.9.1.5 maintenance release.
Please register to edit this issue
.