Re: [xslt] tail-recursive memory consumption problems?

["William M. Brack" <wbrack mmm com hk>]

I'm afraid I really can't do very much with this.  According to the
referenced bug report, earlier versions of the docbook stylesheet
successfully processed the test file, and only the later version
displayed problems with memory consumption. Results are similar with both
the most current (SVN) versions of libxslt/libxml2, and with considerably
older versions.  This, of course, is not a proof that there is no problem
within libxslt, only that it's not something simple which has been caused
by a recent change.

Trying to use a docbook transformation for debugging libxslt requires far
more time than I have available.  If you believe that the very large
memory growth is caused by libxslt (either a bug or a design fault), then
try to produce a reasonably small example stylesheet and xml file which
can be used to demonstrate the problem.

Regards,

Bill

Jeroen Ruigrok/asmodai wrote:
> I am acting as proxy for trying to pin-point this problem, so please
> excuse
> some of my vagueness.
>
> On the DocBook IRC channel someone called attention to the bugreport at
> https://sourceforge.net/tracker/index.php?func=detail&aid=1661177&group_id=21935&atid=373747
>
> This problem report involves a file
> http://www.aao.gov.au/local/www/ss/tmp/fvwm.1.xml which gets transformed
> using
> a simple call of 'xsltproc /path/to/docbook-xsl/manpages/docbook.xsl
> fvwm.1.xml'.
>
> The original submitter of this report has some older versions of libxml
> and
> libxslt, but I tested it with my versions and also went up to way over
> 218 MB
> before I had to kill off the process since this gateway box has only 384
> MB.
>
> My versions:
>
> Using libxml 20627, libxslt 10120 and libexslt 813
> xsltproc was compiled against libxml 20627, libxslt 10120 and libexslt
> 813
> libxslt 10120 was compiled against libxml 20627
> libexslt 813 was compiled against libxml 20627
>
> Norm Walsh provided another version of apply-string-subst-map to see if
> it
> solved the problem, but it didn't. This is the replacement code:
>
> <xsl:template name="apply-string-subst-map">
>   <xsl:param name="content"/>
>   <xsl:param name="map.contents"/>
>
>   <xsl:choose>
>     <xsl:when test="$map.contents">
>       <xsl:call-template name="apply-string-subst-map">
>         <xsl:with-param name="content">
>           <xsl:call-template name="string.subst">
>             <xsl:with-param name="string" select="$content"/>
>             <xsl:with-param name="target"
> select="$map.contents[1]/@oldstring"/>
>             <xsl:with-param name="replacement"
> select="$map.contents[1]/@newstring"/>
>           </xsl:call-template>
>         </xsl:with-param>
>         <xsl:with-param name="map.contents"
> select="$map.contents[position() &gt; 1]"/>
>       </xsl:call-template>
>     </xsl:when>
>     <xsl:otherwise>
>       <xsl:value-of select="$content"/>
>     </xsl:otherwise>
>   </xsl:choose>
> </xsl:template>
>
> Could it be that libxslt is not efficient with tail-recursive operations?
>
> Thanks for any ideas/suggestions/hints,
>
> (Please feel free to post in that sourceforge tracker as well)
>
> --
> Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
> ã?¤ã?§ã?«ã?¼ã?³ ã?©ã?¦ã??ã?­ã??ã?¯ ã?´ã?¡ã?³ ã??ã?« ã?¦ã?§ã?«ã?´ã?§ã?³
> http://www.in-nomine.org/ | http://www.rangaku.org/
> About all you can do in life is be who you are. Some people will love you
> for you. Most will love you for what you can do for them, and some won't
> like
> you at all.