Re: [xml] xmlParserCtxt Leak?

[Daniel Veillard <veillard redhat com>]

On Sun, Jun 15, 2008 at 10:29:28AM -0700, Michael Tremel wrote:
> Thank you for your reply. I realize that I may have been brush in  
> accusing your work; I apologize. I've made the changes you've  

  Not the problem. The problem is that you think you have a leak but
do not provide any evidence of it, you blindly think you have a leak
in some part of the code because valgrind reports unreachable block
when running a program.
But you don't seems to have tried very basic things trying to demonstrate
the "leak" like putting the suspected section of code in a huge loop
or similar testing reproducing the problem. 

> suggested, but the same results from Valgrind keep showing up. Even  
> after adding xmlParserCleanup(), there are 10 allocs and 9 frees  
> leaving 84 bytes "still reachable". I can post more information if you  

  I don't see any leak myself using the version compiled with memory debug

wei:~/XML -> cat tst.c
#include <libxml/parser.h>

int main()
{
        xmlParserCtxtPtr ctxt = xmlNewParserCtxt();
        xmlInitParserCtxt(ctxt);

        xmlFreeParserCtxt(ctxt);

        xmlCleanupParser();

        xmlMemoryDump();
        return 0;
}
wei:~/XML -> ./tst
wei:~/XML -> cat .memdump 
      08:51:36 AM

      MEMORY ALLOCATED : 0, MAX was 4304
BLOCK  NUMBER   SIZE  TYPE
wei:~/XML -> date
Mon Jun 16 08:51

  the 
   ==7788==    still reachable: 144 bytes in 2 blocks.
are likely to be the per-thread data which is not indicative of a 
leak.

> need it, and I will try to compile this against a library with mem- 
> debug as soon as possible.
>
> Also, while I am a beginner, I have read everything there is to read  
> on xmlsoft.org. I'll take a look myself at the source, but I simply  
> felt it was better left in the hands of people who know what they're  
> doing.

  Really for this kind of things it's not a matter of reading the source
it's a matter of having a systematic and rational approach to the problem.
You think some code leaks. Just put it in a loop and run to check. Relying on
an external tool where you don't fully understand the principle or report
just can't replace trying to understand the problem.
  I don't know how many thousands of people use libxml2 every day,
but I know how many people have time to answer on the list, that's not
a lot. On the other hand it takes 2mn to try the same code with

        for (i = 0; i < 10000000;i++) {
            ctxt = xmlNewParserCtxt();

            xmlInitParserCtxt(ctxt);
            xmlFreeParserCtxt(ctxt);
        }

or 

        ctxt = xmlNewParserCtxt();
        for (i = 0; i < 10000000;i++) {
            xmlInitParserCtxt(ctxt);
        }
        xmlFreeParserCtxt(ctxt);

and see it does not leak. So the programe or even derivatives from it don't
show any memory usage growth.

  You may have a leak in your code. The code you gave us to invastigate does
not reproduce it. How are we supposed to help with incomplete data/code ?

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/