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

On Thu, Sep 26, 2002 at 02:34:35PM -0700, Sean Chittenden wrote:
ctxtClose is a blatant rip off from someplace inside of the libxml

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

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

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

==19278== Invalid read of size 2
==19278==    at 0x40308789: (within /lib/
==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/
==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).
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*.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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