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

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

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