Project

Profile

Help

Bug #2756

closed

NullPointerException in TypeHierarchy.relationship using xsl:value-of on a map

Added by Michael Kay almost 8 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
2016-05-24
Due date:
% Done:

100%

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

Description

Reported here:

https://saxonica.plan.io/boards/3/topics/6411?pn=1

The stylesheet

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:xs="http://www.w3.org/2001/XMLSchema" 

xmlns:math="http://www.w3.org/2005/xpath-functions/math" 

xmlns:map="http://www.w3.org/2005/xpath-functions/map" 

xmlns:mf="http://example.com/mf" 

exclude-result-prefixes="xs math map mf" 

version="3.0">    


<xsl:function name="mf:f1">

    <xsl:sequence select="map { 'value' : 0 }"/>

</xsl:function>


<xsl:template match="/" name="xsl:initial-template">

    <xsl:value-of select="mf:f1()"/>

</xsl:template>

</xsl:stylesheet>

when run with Saxon 9.7.0.5 EE and HE causes a NullPointerException, the complete stack trace is

java.lang.NullPointerException

    at net.sf.saxon.type.TypeHierarchy.relationship(TypeHierarchy.java:298)

    at net.sf.saxon.type.TypeHierarchy.isSubType(TypeHierarchy.java:280)

    at net.sf.saxon.expr.AtomicSequenceConverter.typeCheck(AtomicSequenceConverter.java:152)

    at net.sf.saxon.expr.Operand.typeCheck(Operand.java:185)

    at net.sf.saxon.expr.Expression.typeCheckChildren(Expression.java:428)

    at net.sf.saxon.expr.SystemFunctionCall.typeCheck(SystemFunctionCall.java:82)

    at net.sf.saxon.expr.Operand.typeCheck(Operand.java:185)

    at net.sf.saxon.expr.Expression.typeCheckChildren(Expression.java:428)

    at net.sf.saxon.expr.instruct.SimpleNodeConstructor.typeCheck(SimpleNodeConstructor.java:131)

    at net.sf.saxon.style.XSLTemplate.optimize(XSLTemplate.java:793)

    at net.sf.saxon.style.PrincipalStylesheetModule.optimizeTopLevel(PrincipalStylesheetModule.java:1349)

    at net.sf.saxon.style.PrincipalStylesheetModule.compile(PrincipalStylesheetModule.java:1199)

    at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:245)

    at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:260)

    at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:101)

    at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:839)

    at net.sf.saxon.Transform.doTransform(Transform.java:727)

    at net.sf.saxon.Transform.main(Transform.java:77)
Actions #1

Updated by Michael Kay almost 8 years ago

Added to XSLT3 test suite as maps-907. Problem reproduced.

Actions #2

Updated by Michael Kay almost 8 years ago

  • Status changed from In Progress to Resolved

Patched Atomizer.getAtomizedItemType() to return xs:error rather than null if it is known statically that atomization will raise an error. Although the Javadoc for the method specified that it should return null in this case, neither of the two calls on the method were handling a null response correctly.

Actions #3

Updated by Michael Kay almost 8 years ago

  • Applies to branch 9.8 added
  • Fix Committed on Branch 9.7, 9.8 added
Actions #4

Updated by O'Neil Delpratt almost 8 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.7.0.6 added

Bug fixed in maintenance release 9.7.0.6.

Actions #5

Updated by O'Neil Delpratt almost 7 years ago

  • Fix Committed on Branch trunk added
  • Fix Committed on Branch deleted (9.8)
Actions #6

Updated by O'Neil Delpratt almost 7 years ago

  • Applies to branch deleted (9.8)

Please register to edit this issue

Also available in: Atom PDF