Re: [xslt] Segmentation faults returning variable value from exslt functions II

["Marc Adkins" <madkins whitepages com>]

Our XSLT is VERY VERY LARGE.  Our total body of stylesheets is on the
order of 17 Mb, though not all are part of any given page.  We estimate
that each page we generate takes up an average of 50 Mb of memory space
in RAM during use.  This includes the top-level stylesheet and all
relevant imports.

I have also tried to create very small test cases and they always pass.
It's quite frustrating.  Believe me, if I had a simple case I would send
it along.  I'm trying to decide right now whether to try slimming down
our big pile of foo or building a debuggable version of the libraries.
I suspect the former will be less painful.

Since we can reproduce this with xsltproc alone (using, of course, our
entire stylesheet complex) the remainder of the code shouldn't matter.
For the record, this is a mod_perl implementation under Apache 1.3.

Note that the segfaults were occurring with the previous release as well
as the current release which we built from source.  The newer release
has less of them overall, but the cluster related to func:result usage
has been constant.

mma

> -----Original Message-----
> From: xslt-bounces gnome org [mailto:xslt-bounces gnome org] 
> On Behalf Of William M. Brack
> Sent: Thursday, June 14, 2007 2:22 PM
> To: The Gnome XSLT library mailing-list
> Subject: Re: [xslt] Segmentation faults returning variable 
> value from exslt functions II
> 
> Marc Adkins wrote:
> > I have another example of segmentation faults when returning values 
> > from exslt functions.  Again, I can't give you a minimal test 
> > stylesheet (durn it), but this one has a slightly different 
> > configuration and the solution may be of interest.
> >
> > The function itself is a pretty straightforward substitute for the 
> > non-existent fn:lower-case() xpath function:
> >
> >     <func:function name="wpn:lowercase">
> >         <xsl:param name="str" />
> >         <func:result
> > select="translate($str,$upper_alphabet,$lower_alphabet)" />
> >     </func:function>
> >
> > In this case I was not able to modify the function itself 
> so as to get 
> > rid of the segmentation fault.  Nothing worked.
> >
> > The original place where the segfault was happening was the line:
> >
> >     <xsl:variable name="lower" select="wpn:lowercase(string(.))" />
> >
> > The following modification removed the segfault:
> >
> >     <xsl:variable name="lower">
> >         <xsl:value-of select="wpn:lowercase(string(.))" />
> >     </xsl:variable>
> >
> > Interesting, neh?
> 
> Well, it's really not too interesting to try to make 
> assumptions about code taken out of context.  You are 
> reporting that there is a failure with the libxslt/libxml2 
> library, but the code that produces it is something you can't 
> tell us about.  That, of course, makes it rather difficult to 
> try to fix.
> 
> Taking what you have set down, I produced the following xslt file:
> 
> [bill bbsf work]$ cat bug1.xsl
> <xsl:stylesheet version="1.0"
>                 xmlns:foo="http://foo.com/bar";
>                 xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
>                 xmlns:func="http://exslt.org/functions";
>                 extension-element-prefixes="func foo">
> 
> <xsl:variable name="upper" select="'ABCDE'"/> <xsl:variable 
> name="lower" select="'abcde'"/> <func:function name="foo:myfunc">
>         <xsl:param name="param"/>
>         <func:result select="translate($param, $upper, 
> $lower)"/> </func:function>
> 
> <xsl:template match="/">
>   <xsl:variable name="myvar" select="foo:myfunc('ABC')"/>
>   <xsl:value-of select="$myvar"/>
> </xsl:template>
> 
> </xsl:stylesheet>
> 
> Then, I ran that through the previously-released version of 
> xsltproc (my distro hasn't yet distributed the versions 
> release a day or two ago):
> 
> [bill bbsf work]$ xsltproc --version
> Using libxml 20628, 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 [bill bbsf work]$ 
> xsltproc bug1.xsl bug1.xsl <?xml version="1.0"?> abc [bill bbsf work]$
> 
> No segfault.  And, just to make sure, I also ran that through 
> Valgrind, with similar result.  So, since you can't tell us 
> anything more about your code, can you at least give a hint 
> as to how it differs from the above?
> 
> >
> > I have done some cursory code inspection.  All that bought 
> me was the 
> > knowledge that cursory code inspection was insufficient.  Duh.
> >
> > I can duplicate this with xsltproc and our entire body of 
> templates.  
> > I would take a whack at debugging through at this point if 
> I knew how 
> > to get started with the debugger with libxml/libxslt.  For example, 
> > are there debugging parameters to make?  Is there a web page giving 
> > hints on this?
> >
> 
> Debugging is certainly not for the faint at heart, and for 
> someone with no previous experience at low-level tracing 
> through both the libxslt and
> libxml2 libraries would probably be a rather lengthy exercise.
> 
> > Thanks,
> > Marc M. Adkins
> 
> Regards,
> Bill
> 
> _______________________________________________
> xslt mailing list, project page http://xmlsoft.org/XSLT/ 
> xslt gnome org http://mail.gnome.org/mailman/listinfo/xslt
>