Re: [xml] Any outstanding bugs in closing parser contexts or running with different memory handlers?



ctxtClose is a blatant rip off from someplace inside of the libxml
sources:

static void ctxtClose(FILE *f) {
  if (f != stdin) {
    fclose(f);
  }
}


... so I'm not really sure why I'm getting the following cryptic
error:

==19278== Invalid read of size 1
==19278==    at 0x40308758: (within /lib/libc-2.2.5.so)
==19278==    by 0x431B10BC: ctxtClose (ruby_xml_parser.c:17)

==19278== Invalid read of size 2
==19278==    at 0x40308789: (within /lib/libc-2.2.5.so)
==19278==    by 0x431B10BC: ctxtClose (ruby_xml_parser.c:17)
==19278==    by 0x432BCDAA: xmlFreeParserInputBuffer (xmlIO.c:1575)

==19278== Invalid read of size 4
==19278==    at 0x403087CB: (within /lib/libc-2.2.5.so)
==19278==    by 0x431B10BC: ctxtClose (ruby_xml_parser.c:17)
==19278==    by 0x432BCDAA: xmlFreeParserInputBuffer (xmlIO.c:1575)

What's interesting is that the read size grows from 1 to 4.  Why I'm
not sure, and think that there could be a stray bit being written to
in Ruby, but I'm not 100% sure.  Since valgrind only runs on Linux,
I'd perfectly happy to chalk this up as a linux-ism, but it crashes on
FreeBSD too.  :-/  Anyone have any thoughts?  -sc

  Hum, how are those InputBuffer created ? The fact that the read
size changes may simply be due to buffer access informations. Note
that some optimizations from GCC can actually lead to such invalid
read warnings from valgrind, it can also be processor dependant
(e.g. Athlon vs. PIII).

xmlCreateMemoryParserCtxt()

I'm going back and recompiling without any -O optimizations to see if
that helps, but I'm seeing this on gcc 2.9.4 and 3.2.

Make sure you have the latest valgrind 1.0.1, if needed get in touch
with valgrind author, and get a debug version of the C library to
see exactly where this occurs *inside*.

1.0.3 work?  I'm going to see if I can't get a hold of a debug versions
of the core libs, but the only linux box I have access to isn't mine.
:)  Thanks for the pointers though.  -sc

-- 
Sean Chittenden



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