Re: [xslt] Abort processing unknown variables inside translation



In message <20011006035513.J10948@redhat.com>
          Daniel Veillard <veillard@redhat.com> wrote:

> On Sat, Oct 06, 2001 at 08:49:08AM +0100, Justin Fletcher wrote:
> > I know; my point was that it caused an abort - I don't mind it failing
> > on such things, but aborting is generally pretty bad.
>
>   I just tested, it does not crash on linux.
> Can you refine the analysis on your platform and find which line in the
> code leads to the crash ?

Yup... Just about 15 minutes to build with debug though :-|

xmlUTF8Strlen, c.encoding, line 101 :

    while (*utf != 0) {

utf is *(unsigned long *)0 = 0xe59ff40c at this point, and there's no memory
there. Actually the first 7 values in memory are the same thing, so it could
be that any one of those has been dereferenced.

That's called from c.xpath, line 5928 (in xmlXPathTranslateFunction)

	max = xmlUTF8Strlen(to->stringval);

to is assigned using valuePop(ctxt) a few lines earlier. This has returned
a 0 - it's a macro so I assume it's just looking at an array or something
(conjecture, not research).

A quick look at the code in xpath shows a number of places where valuePush
(which I assume is the converse of valuePop) is called with the result of
xmlXPathObjectCopy - a function which can return NULL on memory allocation
failure and if passed a NULL. I don't know if that's a fault or safe in the
positions it has been used, but it's a potential place where a null might
come from.

Does that help ? Do you need more information ?

-- 
Gerph {djf0-.3w6e2w2.226,6q6w2q2,2.3,2m4}
URL: http://www.movspclr.co.uk/
... Eyes to the heavens, screaming at the sky;
    Trying to send you messages, but choking on goodbye.




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