Re: [xml] Memory trouble with libxml.



On Thu, Oct 25, 2001 at 10:54:16AM -0700, Nicholas Palmer wrote:
  What about reading the doc ?

I did read that section, but it was not clear to me that I needed to call
xmlCleanupParser, since I had not parsed anything, I had simply built a
tree from scratch. Furthermore, calling that function at the end of
building my tree does not in fact fix the memory leak that I am seeing. If
I place a loop around the main section of the code the memory usage grows
for every loop, which indicates that it is not the parsers static
structures that are leaking.

  Okay, that's useful information that you didn't gave, right ?

Daniel, not very happy to have to repeat over and over and over the same
        stuff written clearly in the f...ing documentation.

It is obviously not clearly written if I read that section, and did not
understand that this was required when parsing _and_ when building a tree
from scratch. Good documentation is more elusive than you think, as human

  To know whether xmlCleanupParser() call is needed it means I need
to fully understand your code. In general when using libxml this call
is needed. This may not be the case there, I can't be sure, creating
attribute nodes from string for example may require checking whether
entities are declared, which may call the entity code, which may
initialize the predefined entities which will need xmlCleanupParser() ...
or not!

language is extremely flexible. Furthermore, that does not fix the problem
I am seeing. I understand your frustration. Please try to understand mine.

  That section also include a detailed way to debug any possible memory
allocation problem. You recompile the library with memory debugging
add a call at the end of your program check the conent of the .memdump
output. From there you have allocation number which failed to be freed.
There is also explanations on how to put a breakpoint in gdb to block
the program when that block is allocated.

  That is a *reproductible process* that is IMHO understandable, which
allow to pinpoint precisely the errors in memory allocation and chase them.

  Basically if you don't do it, I would have to do it to give you an
answer. I can't magically scan contributed code and tell "the error is
there". Sorry I doesn't scale. The process given does scale. I also 
say in the section on reporting bugs that I can't debug other people
code:
   http://xmlsoft.org/bugs.html

  It is possible that libxml has a bug, that your code makes apparent,
or uses libxml in a way which makes it loose memory from the tree.

  But it seems you didn't followed those instructions. It's part of
my frustration. Expecting others to do the work, and it seems, taking
this for granted.

  All I can see at  a first glance it that the array is not freed but
that does not correspond with your report.
  Doing
      xmlNewTextChild(attribute_node,NULL,COLUMN_TAG,array[i].columnId);
      xmlNewTextChild(attribute_node,NULL,VALUE_TAG,array[i].value);
also probably expect adjacent text nodes to be created, while they
are gonna be coalesced into a single text node, and there is other
bizarre things like call xmlNodeDump using a document node instead
of xmlDocDump, and the couple of comments are rather confusing (no
attribute node are created, only element or text ones).

  I just tried to compile the fragment of code:

orchis:~/XML -> gcc -O -g -Wall -Iinclude/ -o tst tst.c .libs/libxml2.a -lz
tst.c:9: `attribute' redeclared as different kind of symbol
include/libxml/SAX.h:80: previous declaration of `attribute'
tst.c: In function `main':
tst.c:70: warning: implicit declaration of function `sleep'
tst.c:57: warning: unused variable `value'
tst.c:57: warning: unused variable `column'
orchis:~/XML -> 

 I had to modify the program to have it compile (renaming the struct).
I then had to modify to not fail because you used free() to free
the memory allocate with xmlStrdup() (part.xml)

 None of the element allocated are ever freed. You never attached the
node account_node to the document doc, you just passed a reference 
but it's not sufficient, that's the cause of the problem.
  xmlAddChild(doc, account_node)
 should cure this.
 There is an example to build a tree from scratch in
   http://xmlsoft.org/library.html

it does:

 doc = xmlNewDoc("1.0");
 doc->children = xmlNewDocNode(doc, NULL, "EXAMPLE", NULL);

 which could have helped you realizing that such nodes created need to
be added to the tree.

  I really hate going through the exercise of debugging someone else code,
especially when it's not really clean. I did it. I object doing it in general.
Debugging methodology MUST be learnt (I teach system courses, it's one of
the main weaknesses of my students, every year ...). I think that providing
the tools and the guidelines to do thing in a reliable way is what I should
do (and test/document my code too of course).
 I don't think I should debug other people code (unless being paid, and
that so boring that I would probably switch jobs if I had).

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



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