http://swpat.ffii.org/
Action against software patents
http://www.gnome.org/
Gnome2 Logo
http://www.w3.org/Status
W3C Logo
http://www.redhat.com/
Red Hat Logo
http://xmlsoft.org/
Made with Libxml2 Logo
The XML C parser and toolkit of Gnome
Memory Management
Developer Menu
index.html
Main Menu
html/index.html
Reference Manual
examples/index.html
Code Examples
guidelines.html
XML Guidelines
tutorial/index.html
Tutorial
xmlreader.html
The Reader Interface
ChangeLog.html
ChangeLog
XSLT.html
XSLT
python.html
Python and bindings
architecture.html
libxml2 architecture
tree.html
The tree output
interface.html
The SAX interface
xmlmem.html
Memory Management
xmlio.html
I/O Interfaces
library.html
The parser interfaces
entities.html
Entities or no entities
namespaces.html
Namespaces
upgrade.html
Upgrading 1.x code
threads.html
Thread safety
DOM.html
DOM Principles
example.html
A real example
xml.html
flat page
,
site.xsl
stylesheet
API Indexes
APIchunk0.html
Alphabetic
APIconstructors.html
Constructors
APIfunctions.html
Functions/Types
APIfiles.html
Modules
APIsymbols.html
Symbols
Related links
http://mail.gnome.org/archives/xml/
Mail archive
http://xmlsoft.org/XSLT/
XSLT libxslt
http://phd.cs.unibo.it/gdome2/
DOM gdome2
http://www.aleksey.com/xmlsec/
XML-DSig xmlsec
ftp://xmlsoft.org/
FTP
http://www.zlatkovic.com/projects/libxml/
Windows binaries
http://www.blastwave.org/packages.php/libxml2
Solaris binaries
http://www.explain.com.au/oss/libxml2xslt.html
MacOsX binaries
http://libxmlplusplus.sourceforge.net/
C++ bindings
http://www.zend.com/php5/articles/php5-xmlphp.php#Heading4
PHP bindings
http://sourceforge.net/projects/libxml2-pas/
Pascal bindings
http://rubyforge.org/projects/xml-tools/
Ruby bindings
http://tclxml.sourceforge.net/
Tcl bindings
http://bugzilla.gnome.org/buglist.cgi?product=libxml2
Bug Tracker
Table of Content:
#General3
General overview
#setting
Setting libxml2 set of memory routines
#cleanup
Cleaning up after parsing
#Debugging
Debugging routines
#General4
General memory requirements
General overview
The module
http://xmlsoft.org/html/libxml-xmlmemory.html
xmlmemory.h
provides the interfaces to the libxml2 memory system:
libxml2 does not use the libc memory allocator directly but xmlFree(),
xmlMalloc() and xmlRealloc()
those routines can be reallocated to a specific set of routine, by
default the libc ones i.e. free(), malloc() and realloc()
the xmlmemory.c module includes a set of debugging routine
Setting libxml2 set of memory routines
It is sometimes useful to not use the default memory allocator, either for
debugging, analysis or to implement a specific behaviour on memory management
(like on embedded systems). Two function calls are available to do so:
http://xmlsoft.org/html/libxml-xmlmemory.html
xmlMemGet
()
which return the current set of functions in use by the parser
http://xmlsoft.org/html/libxml-xmlmemory.html
xmlMemSetup()
which allow to set up a new set of memory allocation functions
Of course a call to xmlMemSetup() should probably be done before calling
any other libxml2 routines (unless you are sure your allocations routines are
compatibles).
Cleaning up after parsing
Libxml2 is not stateless, there is a few set of memory structures needing
allocation before the parser is fully functional (some encoding structures
for example). This also mean that once parsing is finished there is a tiny
amount of memory (a few hundred bytes) which can be recollected if you don't
reuse the parser immediately:
http://xmlsoft.org/html/libxml-parser.html
xmlCleanupParser
()
is a centralized routine to free the parsing states. Note that it
won't deallocate any produced tree if any (use the xmlFreeDoc() and
related routines for this).
http://xmlsoft.org/html/libxml-parser.html
xmlInitParser
()
is the dual routine allowing to preallocate the parsing state
which can be useful for example to avoid initialization reentrancy
problems when using libxml2 in multithreaded applications
Generally xmlCleanupParser() is safe, if needed the state will be rebuild
at the next invocation of parser routines, but be careful of the consequences
in multithreaded applications.
Debugging routines
When configured using --with-mem-debug flag (off by default), libxml2 uses
a set of memory allocation debugging routines keeping track of all allocated
blocks and the location in the code where the routine was called. A couple of
other debugging routines allow to dump the memory allocated infos to a file
or call a specific routine when a given block number is allocated:
http://xmlsoft.org/html/libxml-xmlmemory.html
xmlMallocLoc()
http://xmlsoft.org/html/libxml-xmlmemory.html
xmlReallocLoc()
and
http://xmlsoft.org/html/libxml-xmlmemory.html
xmlMemStrdupLoc()
are the memory debugging replacement allocation routines
http://xmlsoft.org/html/libxml-xmlmemory.html
xmlMemoryDump
()
dumps all the informations about the allocated memory block lefts
in the
.memdump
file
When developing libxml2 memory debug is enabled, the tests programs call
xmlMemoryDump () and the "make test" regression tests will check for any
memory leak during the full regression test sequence, this helps a lot
ensuring that libxml2  does not leak memory and bullet proof memory
allocations use (some libc implementations are known to be far too permissive
resulting in major portability problems!).
If the .memdump reports a leak, it displays the allocation function and
also tries to give some informations about the content and structure of the
allocated blocks left. This is sufficient in most cases to find the culprit,
but not always. Assuming the allocation problem is reproducible, it is
possible to find more easily:
write down the block number xxxx not allocated
export the environment variable XML_MEM_BREAKPOINT=xxxx , the easiest
when using GDB is to simply give the command
set environment XML_MEM_BREAKPOINT xxxx
before running the program.
run the program under a debugger and set a breakpoint on
xmlMallocBreakpoint() a specific function called when this precise block
is allocated
when the breakpoint is reached you can then do a fine analysis of the
allocation an step  to see the condition resulting in the missing
deallocation.
I used to use a commercial tool to debug libxml2 memory problems but after
noticing that it was not detecting memory leaks that simple mechanism was
used and proved extremely efficient until now. Lately I have also used
http://developer.kde.org/~sewardj/
valgrind
with quite some
success, it is tied to the i386 architecture since it works by emulating the
processor and instruction set, it is slow but  extremely efficient, i.e. it
spot memory usage errors in a very precise way.
General memory requirements
How much libxml2 memory require ? It's hard to tell in average it depends
of a number of things:
the parser itself should work  in a fixed amount of memory, except for
information maintained about the stacks of names and  entities locations.
The I/O and encoding handlers will probably account for a few KBytes.
This is true for both the XML and HTML parser (though the HTML parser
need more state).
If you are generating the DOM tree then memory requirements will grow
nearly linear with the size of the data. In general for a balanced
textual document the internal memory requirement is about 4 times the
size of the UTF8 serialization of this document (example the XML-1.0
recommendation is a bit more of 150KBytes and takes 650KBytes of main
memory when parsed). Validation will add a amount of memory required for
maintaining the external Dtd state which should be linear with the
complexity of the content model defined by the Dtd
If you need to work with fixed memory requirements or don't need the
full DOM tree then using the
xmlreader.html
xmlReader
interface
is probably the best way to proceed, it still allows to
validate or operate on subset of the tree if needed.
If you don't care about the advanced features of libxml2 like
validation, DOM, XPath or XPointer, don't use entities, need to work with
fixed memory requirements, and try to get the fastest parsing possible
then the SAX interface should be used, but it has known restrictions.
bugs.html
Daniel Veillard
