We've been seeing segmentation faults returning variable values via func:result. This was happening with:
Using libxml 20628, libxslt 10120 and libexslt 813
xsltproc was compiled against libxml 20628, libxslt 10120 and libexslt 813
libxslt 10120 was compiled against libxml 20628
and is still happening with:
Using libxml 20629, libxslt 10121 and libexslt 813
xsltproc was compiled against libxml 20629, libxslt 10121 and libexslt 813
libxslt 10121 was compiled against libxml 20629
libexslt 813 was compiled against libxml 20629
which is otherwise working as we expect (though we're still testing it).
What we're finding is that exslt functions of the form:
<func:function>
<xsl:variable name="result">
<!-- some calculation -->
</xsl:variable>
<func:result select="$result" />
</func:function>
tend to segfault whereas:
<func:function>
<func:result>
<!-- some calculation -->
</func:result>
</func:function>
work fine. This is a benign change and an acceptable work-around.
Unfortunately, this will only happen for us in the context of our full set of templates, which is quite large. We are using XSLT very heavily to generate our entire site. We also have a lot of XSLT bugs that we're only finding due to the upgrade from our current production version (
Using libxml 20608, libxslt 10105 and libexslt 804
xsltproc was compiled against libxml 20608, libxslt 10105 and libexslt 804
libxslt 10105 was compiled against libxml 20608
libexslt 804 was compiled against libxml 20608
) since the newer version has better error checking. My point being that I have been unable to create a minimal XSLT file that demonstrates the problem. I'd have to send you our entire template library and I'm unable to do so.
We can now get the segfault using xsltproc directly. I'd like to say that I'm going to debug into it and find the problem, but sadly I'm unable to take the time. We're kind of in a crunch as a major project blew up the older version we've been using for three years and this upgrade process is a fire drill.
So all I can do right now is report the problem. I don't expect a fix or anything, this is just in case somewhere down the road my comments make the issue clearer for someone else. I can definitely recommend our work-around as an interim fix for this problem.
I would also ask if anyone knows for certain that the work-around is in fact required by some specification. Certainly we have no right to expect improper XSLT to work. I'm just not seeing anything preventing our original usage, which we apparently adopted several years ago from published examples.
Marc M. Adkins
BEGIN:VCARD VERSION:2.1 N:Adkins;Marc FN:Marc Adkins ORG:;Engineering TITLE:Software Engineer, Sr. II-Lead TEL;WORK;VOICE:(206) 973-5147 ADR;WORK:;Seattle LABEL;WORK:Seattle EMAIL;PREF;INTERNET:madkins whitepages com REV:20060714T212329Z END:VCARD