Re: [xslt] Abort processing unknown variables inside translation
- From: Justin Fletcher <justin fletcher ntlworld com>
- To: xslt gnome org
- Subject: Re: [xslt] Abort processing unknown variables inside translation
- Date: Sat, 06 Oct 2001 10:06:34 +0100
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]