RE: Parser implemented in XSL -- stack overflow

xsl:apply-templates is a call, just like call-template, and it requires
a new stack frame.

(Actually with Saxon the situation is a little more complex. Saxon uses
the Java stack to handle the calling structure and return address, and
it uses its own stack, which lives in the Java heap, to handle XSLT
parameters and local variables. If you call a template that has no
variables or parameters, then no stackframe is allocated on Saxon's
stack, but it still uses some space on the Java stack to keep track of
the calling hierarchy and return address. When tail-calls are optimized,
which isn't happening here, both stacks are unwound before making the
call.)

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx 

> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx 
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Bill Cohagan
> Sent: 02 April 2003 21:51
> To: XSL-List@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE:  Parser implemented in XSL -- stack overflow
> 
> 
> Michael-
> 
>   You say:
> ===================
> The call:
> 
>     <xsl:apply-templates select="following-sibling::*[1]" mode="sn5">
>       <xsl:with-param name="parents" select="concat($ID, ',', 
> $adjustedParents)" />
>     </xsl:apply-templates>
> 
> will generate a new stack frame for each sibling that is 
> processed. ====================
> 
> I assume that it's not simply the <xsl:apply-template ...> 
> call that pushes stack. What is it about my code that causes 
> stack push? Is it the select expression, the mode, or the use 
> of a param?
> 
> Thanks, 
> 
> Bill
> 
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list