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:[EMAIL PROTECTED]
REV:20060714T212329Z
END:VCARD
_______________________________________________
xslt mailing list, project page http://xmlsoft.org/XSLT/
[email protected]
http://mail.gnome.org/mailman/listinfo/xslt
