I know that a release was just issued, but can we get another one? We're not above running patched code, but our QA department (and pretty much everyone else) would rather use a "named" release in production if at all possible.
Note that William Brack (may the road always rise to meet him) points out that while the code may appear to work it is still accessing freed memory internally. While no one else has run across the problem yet, that may change at any time. This appears to affect all usage of func:result. It's hard to believe that no one else is using EXSLT functions.
Then again, perhaps there's no one else using libXSLT. Hard to believe…
Regardless, thanks very much for the product and even more for Mr. Brack's time over the last few days.
Marc M. Adkins
P.S. As a moderately amusing side note, we finally figured out how we blew up the three year old version of the libraries we were using. We ran afoul of a bug in the hashing algorithm used for variable names, long since fixed. Whoopsie!
> -----Original Message-----
> From: xslt-bounces gnome org [mailto:xslt-bounces gnome org]
> On Behalf Of William M. Brack
> Sent: Tuesday, June 19, 2007 6:54 AM
> To: The Gnome XSLT library mailing-list
> Subject: Re: [xslt] Segmentation faults returning variable
> value from exslt functions II
>
> Daniel Veillard wrote:
> > On Thu, Jun 14, 2007 at 02:37:54PM -0700, Marc Adkins wrote:
> >> 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.
> >
> > I would be you, I would chase the best C guy around, give him a
> > machine with plenty of memory, a very fast CPU, get him to
> recompile
> > xsltproc in debug mode, and then run valgrind on the test
> case. he may
> > get an output good enough to understand what is going on.
> > Debugging is a rational - purely logic - approach especially when
> > you're blessed with a reproductible test case (yes you're lucky !
> > xsltproc is fairly determinist, no threads, no timing ...). You can
> > put your effort where you think is the best return for you. But for
> > the project and potentially for you the best is to get the
> bug fixed,
> > it is 'just' a matter of time for a competent person from where you
> > stand.
> >
> > Daniel
>
> I worked off-list with the original reporter of this problem.
> He was eventually able to provide some specific test data to
> reproduce one case, and with that I was able to debug and
> trace through libxslt. There was a problem within the module
> transform.c concerning the caching of RVT's, which caused the
> segfaults. Interestingly, running under valgrind showed that
> the originally suggested "fix" (changing stylesheets' usage
> of variables within functions) didn't really cure the
> problem; although it didn't segfault, it was still doing some
> accessing of memory which had previously been freed.
>
> A corrected version of transform.c is in SVN, and the
> original reporter has confirmed that this has cured the
> segfaults which were previously being experienced.
>
> Bill
>
> _______________________________________________
> xslt mailing list, project page http://xmlsoft.org/XSLT/
> xslt gnome org http://mail.gnome.org/mailman/listinfo/xslt
>