Re: possible off-by-one error in g_markup_parse_context_parse()

["Alan M. Evans" <ame1 extratech com>]

Ahh, come on guys...

Surely *somebody* has an idea or opinion about this! Even if it's,
"You're annoying. Go away!"

I know that most mentions of valgrind on this list are just brushed
aside, but reading unitialized memory isn't the same as the typical
reports of leaking memory (which are merely annoying). If I'm wrong then
tell me so. If I'm right then this is a bug that ought to be fixed.

I spent considerable company time here, cutting a very large program
down to this minimal example to track the problem. At least someone here
could give me the time of day and acknowledge my report.

On Wed, 2004-05-19 at 11:19, Alan M. Evans wrote:
> Hello All.
> 
> Please observe the following prog:
> 
> -------------------------------------------------------
> #include <glib.h>
> #include <stdio.h>
> 
> static GMarkupParser callbacks = {0,0,0,0,0};
> 
> //char buf[1000]; // no problem
> int main() {
>     char buf[1000]; // problem
>     size_t len;
>     FILE *f;
>     GMarkupParseContext *context;
>     context = g_markup_parse_context_new(
>         &callbacks,(GMarkupParseFlags)0,0,0);
>     f = fopen("SampleCADLibrary.xmm","r");
>     do {
>         if ((len = fread(buf,1,1000,f))>0) {
>             g_markup_parse_context_parse(context,buf,len,0);
>         }
>     } while(!feof(f) && !ferror(f));
>     fclose(f);
>     g_markup_parse_context_free(context);
>     return 0;
> }
> -------------------------------------------------------
> 
> When run in valgrind, produces the following:
> 
> ==9236== Conditional jump or move depends on uninitialised value(s)
> ==9236==    at 0x40258C28: (within /usr/lib/libglib-2.0.so.0.400.0)
> ==9236==    by 0x40258CF4: (within /usr/lib/libglib-2.0.so.0.400.0)
> ==9236==    by 0x402595C0: g_markup_parse_context_parse (in
> /usr/lib/libglib-2.0.so.0.400.0)
> ==9236==    by 0x80486D9: main (gmarkup_test.c:17)
> 
> But when I change the location of the buf array (see code), the error is
> not reported. I initially thought that this was valgrind misreporting,
> but, on a whim, I replaced the array with a char pointer using
> g_new/g_free and the error changed:
> 
> ==9256== Invalid read of size 1
> ==9256==    at 0x40258C25: (within /usr/lib/libglib-2.0.so.0.400.0)
> ==9256==    by 0x40258CF4: (within /usr/lib/libglib-2.0.so.0.400.0)
> ==9256==    by 0x402595C0: g_markup_parse_context_parse (in
> /usr/lib/libglib-2.0.so.0.400.0)
> ==9256==    by 0x8048751: main (gmarkup_test.c:19)
> ==9256==    Address 0x412B740C is 0 bytes after a block of size 1000
> alloc'd
> ==9256==    at 0x400296B2: malloc (vg_replace_malloc.c:153)
> ==9256==    by 0x4025ACB0: g_malloc (in /usr/lib/libglib-2.0.so.0.400.0)
> ==9256==    by 0x80486C4: main (gmarkup_test.c:13)
> ==9256==    by 0x402C3AB6: __libc_start_main (in /lib/libc-2.3.2.so)
> 
> I checked and the reported address is, indeed, buf + 1000 -- that is,
> one byte out of bounds. If glib is reading this address then we do have
> a bug on our hands. Otherwise, it could still be valgrind screwing up,
> but I'd like someone more familiar with the gmarkup code to confirm
> this. Obviously, the xml file has to be larger than the buffer (1000
> bytes) to see this.
> 
> I'm using glib-2.4.0 (upgraded from the RH9 stock 2.2.X when I first
> observed this problem), which is the latest I could find an RPM for.
> (New RPM is from Fedora Core 2).
> 
> Thanks!