Project

Profile

Help

Bug #1653

closed

java.lang.NullPointerException thrown in tail recursive user defined function

Added by O'Neil Delpratt over 11 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Normal
Category:
Byte code generation
Sprint/Milestone:
-
Start date:
2012-12-04
Due date:
% Done:

100%

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

Description

In a user defined function which has a tail recursive call, we observe When bytecode generation is on, the exception java.lang.NullPointerException is thrown. This occurs when the tail call is within a singleton for-loop which at runtime may be ran zero or one time.

The exception can be reproduced with the following function (taken from http://dnovatchev.wordpress.com/):

<xsl:function name="my:processQueue"  as="xs:string*">
  <xsl:param name="pQueue" as="element()*"/>
  <xsl:param name="pTarget" as="xs:string"/>
  <xsl:param name="pExcluded" as="xs:string*"/>
  
  <xsl:sequence select=
   "if(not($pQueue))
      then ()
      else for $vTop in $pQueue[1],
               $vResult in my:processNode($vTop, $pTarget, $pExcluded)[1]
		         return
		           if($vResult/self::result)
					       then string-join($vResult/*, ' ==> ')
					       else my:processQueue((subsequence($pQueue, 2), $vResult/*),
					                            $pTarget,
					                            ($pExcluded, $vResult/*/value)
					                           )"/>
 </xsl:function>
Actions #1

Updated by O'Neil Delpratt over 11 years ago

  • Description updated (diff)
  • Status changed from New to Resolved
  • % Done changed from 0 to 100

In the ForExpressionCompiler class we have added code generation to special case the ForExpression sequence which has cardinality 0 or 1.

Fix applied and committed to subversion.

Actions #2

Updated by Michael Kay over 11 years ago

Note, this function containing a tail call within a for loop would not normally be considered tail-recursive, but in this case Saxon classifies it as such because it is able to work out that the for loop is iterated at most once. The failure in the byte code generation is concerned specifically with this case.

Actions #3

Updated by O'Neil Delpratt about 11 years ago

  • Status changed from Resolved to Closed
  • Fixed in version set to 9.4.0.7

Bug closed. Fixed in Saxon maintenance release 9.4.0.7

Please register to edit this issue

Also available in: Atom PDF