Re: [xml] libxml and thread

[Daniel Veillard <veillard redhat com>]

On Thu, Jun 25, 2009 at 11:18:15AM +0200, BDM wrote:
> As you purposed I compiled the lib with:
> ./configure --disable-shared --with-run-debug && make
>
> I still have a segmentation fault but this time I activate the  
> coredumping !
> Here is my "tests":
[...]
> Running against valgrind generate no coredump:
> libxml2-2.7.2$ valgrind --leak-check=full --leak-resolution=high
> --track-origins=yes ./runtest
[...]
> ## Catalog and Threads regression tests
> Total 2748 tests, 2 errors, 0 leaks
> ==12391==
> ==12391== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> ==12391== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==12391== malloc/free: 3,032,159 allocs, 3,032,159 frees, 1,453,987,136
> bytes allocated.
> ==12391== For counts of detected errors, rerun with: -v
> ==12391== All heap blocks were freed -- no leaks are possible.
[...]
> Standalone execution generate a coredump:
> libxml2-2.7.2$ ./runtest
> ## XML regression tests
> ## XML regression tests on memory
> ## XML entity subst regression tests
> ## XML Namespaces regression tests
> ## Error cases regression tests
> Error for ./test/errors/webdav.xml failed
> File ./test/errors/webdav.xml generated an error
> ## Error cases stream regression tests
> Error for ./test/errors/webdav.xml failed
> File ./test/errors/webdav.xml generated an error
> ## Reader regression tests
> .
> .
> .
> ## Catalog and Threads regression tests
> Erreur de segmentation

  Well well well...

> libxml2-2.7.2$ gdb ./runtest core
> GNU gdb 6.8-debian
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
[...]
> #0  __xmlParserInputBufferCreateFilename (URI=0x7faf88003648
> "test/threads/acb.dtd", enc=XML_CHAR_ENCODING_NONE) at xmlIO.c:2472
> 2472                if (((z_stream *)context)->avail_in > 4) {
> (gdb) bt

  Context was just allocated in the previous opencallback()
it's tested a couple of line before to be not NULL.
This test is *very* heavilly threaded, so to me it looks like
if you push the memory allocator in threaded testing to the limit
well something breaks either in zlib or in libc.
  And the problem doesn't show up on valgrind because valgrind has
of course his own memory allocator, and reports correct usage from
libxml2 and zlib.
  To me that smells pretty bad, I doubt I can suggest a fix,
those regression tests are run standalone with testThreads.c
run it to verify it reproduces the issue, but that test has been around
for years so this sounds indicative of a low level problem or a
miscompilation in some ways.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/