Re: Unfortunately, not yet solved (Was: Re: Problem solved! (Was: Re: [xml] valgrind errrors with this small sample program))

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

Daniel Veillard said:
> On Wed, Mar 17, 2004 at 04:29:38PM +0100, Holger Rauch wrote:
> > Hi Daniel!
> >
> > My problem *seems* to be solved for lixml2 2.6.7
> > on Linux (valgrind doesn't report any errors),
> > but not when using Purify (a commercial memory analysis tool) on
> > Solaris. The Solaris I'm talking about is 2.8 running on a 64-bit
> > system. I
> > used gcc 2.95.3 to compile my sample program.
> >
> > It seems to me that valgrind does not detect such errors. So,
> > probably it's
> > also an error on Linux; it just doesn't show up in valgrind.
   <snip>
>   Can you try to change line 7567 of parser.c from
>     if ((tlen > 0) && (memcmp(ctxt->input->cur, ctxt->name, tlen) ==
> 0)) {
> to
>     if ((tlen > 0) && (memcmp(ctxt->name, ctxt->input->cur, tlen) ==
> 0)) {
>
>  and see if this fixes Purify report ?
>
> Daniel

If I understand the coding correctly, I'm afraid that won't help. 
This line of code is attempting to match an end tag with the
corresponding start tag, but potential namespaces complicate the
situation (as in the current example).
   ctxt->input->cur
contains a QName, and
   ctxt->name
contains the localname (an NCName).  tlen is the length of the
QName.  The localname is terminated with a '\0', and the code is
assuming that the memcmp will stop as soon as the bytes of the two
names differ.  However, that may not be true, depending upon the
particular implementation of the memcmp function (and possibly the
architecture, e.g. wordsize and boundaries).  Therefore, there is a
possibility that the compare may "run off the end" of the localname.