Re: [xslt] Segmentation fault with an infinite loop



Mike Hommey said:
> William M. Brack wrote:
>>   Could you please let the list know more details about your
>> configuration, and also a copy of your "ulimit -a" output?  If, in
>> fact, your stack space is less than 8192KB, I would suggest you
>> change it up to that figure and see if the problem is solved.
>
> It sounded an interesting track to follow, until i actually checked:
> mh vaio:/tmp$ ulimit -a
> core file size        (blocks, -c) 0
> data seg size         (kbytes, -d) unlimited
> file size             (blocks, -f) unlimited
> max locked memory     (kbytes, -l) unlimited
> max memory size       (kbytes, -m) unlimited
> open files                    (-n) 1024
> pipe size          (512 bytes, -p) 8
> stack size            (kbytes, -s) unlimited
> cpu time             (seconds, -t) unlimited
> max user processes            (-u) unlimited
> virtual memory        (kbytes, -v) unlimited
>
> stack size is unlimited on my system :(
> The system is a Debian GNU/Linux Sid up to date (and even more,
> since
> the packages for latest releases of libxml2 and libxslt are not yet
> uploaded, only awaiting sponsorship)
> The kernel is a 2.4.22 with a few patches but unrelated to low-level
> stuff.
> I don't really know what kind of informations you need about my
> system,
> so just ask if you need more.
>
> Cheers
>
> Mike

I certainly don't see anything wrong with your settings.  However, I
am still convinced that my analysis is correct - the problem you
reported occurs because of the amount of stack which your process
has available to it.

If you want to further convince yourself, you can play around with
xsltproc under the debugger.  A couple of important points: the
detection and forced termination of excessive recursion is
controlled by the global variable xsltMaxDepth (defined at
transform.c:66, where it is preset to 5000 [number of stored
templates]).  You can try (under the debugger) setting it to a lower
value to see that the detection process properly occurs.  Then, the
comparison of the current template stack level (which is kept at
ctxt->templNr) with this constant happens at templates.c:1484.  You
can put a break on this statement and see that all proceeds well up
to whatever level your stack setting allows (I only know from your
description that this number is < 5000 :-).

As far as a solution, I'm afraid you will have to chase the problem
(of why your process has insufficient stack) through knowlegeable
Debian people (a class of people which does not include me). 
Perhaps other list members can offer further suggestions.

Good luck,

Bill



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]