mirror of
https://gitlab.gnome.org/GNOME/libxml2.git
synced 2025-03-20 18:50:08 +03:00
documentations: - doc/xml.html doc/xmlmem.html: added a module describing
documentations: - doc/xml.html doc/xmlmem.html: added a module describing memory interfaces and use, updated the main page. Daniel
This commit is contained in:
parent
2f971a26da
commit
189446d2fa
@ -1,3 +1,8 @@
|
||||
Fri Oct 13 12:21:48 CEST 2000 Daniel Veillard <Daniel.Veillard@w3.org>
|
||||
|
||||
* doc/xml.html doc/xmlmem.html: added a module describing memory
|
||||
interfaces and use, updated the main page.
|
||||
|
||||
Fri Oct 13 01:23:48 CEST 2000 Daniel Veillard <Daniel.Veillard@w3.org>
|
||||
|
||||
* nanoftp.c nanohttp.c xmlIO.c: Wayne Davison Win32 patch
|
||||
|
@ -14,6 +14,7 @@
|
||||
#undef HAVE_ISNAN
|
||||
#undef HAVE_LIBHISTORY
|
||||
#undef HAVE_LIBREADLINE
|
||||
#undef SOCKLEN_T
|
||||
|
||||
/* Define if you have the class function. */
|
||||
#undef HAVE_CLASS
|
||||
@ -153,5 +154,3 @@
|
||||
/* Define if compiler has function prototypes */
|
||||
#undef PROTOTYPES
|
||||
|
||||
/* Type of socket length (socklen_t) */
|
||||
#undef SOCKLEN_T
|
||||
|
63
doc/xml.html
63
doc/xml.html
@ -3,7 +3,7 @@
|
||||
<html>
|
||||
<head>
|
||||
<title>The XML C library for Gnome</title>
|
||||
<meta name="GENERATOR" content="amaya V3.2">
|
||||
<meta name="GENERATOR" content="amaya V3.2.1">
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
</head>
|
||||
|
||||
@ -53,6 +53,7 @@ alt="W3C Logo"></a></p>
|
||||
libxml2</a></li>
|
||||
<li><a href="encoding.html">libxml Internationalization support</a></li>
|
||||
<li><a href="xmlio.html">libxml Input/Output interfaces</a></li>
|
||||
<li><a href="xmlmem.html">libxml Memory interfaces</a></li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="Introducti">Introduction</a></h2>
|
||||
@ -65,23 +66,29 @@ structured documents/data.</p>
|
||||
|
||||
<p>Here are some key points about libxml:</p>
|
||||
<ul>
|
||||
<li>Libxml exports Push and Pull type parser interfaces for both XML and
|
||||
HTML.</li>
|
||||
<li>Libxml can do Dtd validation at parse time, using a parsed document
|
||||
instance, or with an arbitrary Dtd.</li>
|
||||
<li>Libxml now includes a nearly complete <a
|
||||
href="http://www.w3.org/TR/xpath">XPath</a> and <a
|
||||
href="http://www.w3.org/TR/xptr/">XPointer</a> implementations.</li>
|
||||
<li>It is written in plain C, making as few assumptions as possible, and
|
||||
sticking closely to ANSI C for easy embedding.</li>
|
||||
sticking closely to ANSI C/POSIX for easy embedding. Works on
|
||||
Linux/Unix/Windows, ported to a number of other platforms. </li>
|
||||
<li>Basic support for HTTP and FTP client allowing to fetch remote
|
||||
resources</li>
|
||||
<li>The design of modular, most of the extensions can be compiled out.</li>
|
||||
<li>The internal document repesentation is as close as possible to the <a
|
||||
href="http://www.w3.org/DOM/">DOM</a> interfaces.</li>
|
||||
<li>Libxml also has a <a href="http://www.megginson.com/SAX/index.html">SAX
|
||||
like interface</a>; the interface is designed to be compatible with <a
|
||||
href="http://www.jclark.com/xml/expat.html">Expat</a>.</li>
|
||||
<li>Libxml now includes a nearly complete <a
|
||||
href="http://www.w3.org/TR/xpath">XPath</a> implementation.</li>
|
||||
<li>Libxml exports Push and Pull type parser interfaces for both XML and
|
||||
HTML.</li>
|
||||
<li>This library is released both under the <a
|
||||
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720.html">W3C
|
||||
IPR</a> and the GNU LGPL. Use either at your convenience, basically this
|
||||
should make everybody happy, if not, drop me a mail.</li>
|
||||
<li>There is <a href="upgrade.html">a first set of instructions</a>
|
||||
concerning upgrade from libxml-1.x to libxml-2.x</li>
|
||||
IPR</a> and the <a href="http://www.gnu.org/copyleft/lesser.html">GNU
|
||||
LGPL</a>. Use either at your convenience, basically this should make
|
||||
everybody happy, if not, drop me a mail.</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="Documentat">Documentation</a></h2>
|
||||
@ -125,8 +132,9 @@ structured documents/data.</p>
|
||||
<p>Well, bugs or missing features are always possible, and I will make a point
|
||||
of fixing them in a timely fashion. The best way to report a bug is to use the
|
||||
<a href="http://bugs.gnome.org/db/pa/lgnome-xml.html">Gnome bug tracking
|
||||
database</a>. I look at reports there regularly and it's good to have a
|
||||
reminder when a bug is still open. Check the <a
|
||||
database</a> (make sure to use the "gnome-xml" module name, not libxml or
|
||||
libxml2). I look at reports there regularly and it's good to have a reminder
|
||||
when a bug is still open. Check the <a
|
||||
href="http://bugs.gnome.org/Reporting.html">instructions on reporting bugs</a>
|
||||
and be sure to specify that the bug is for the package gnome-xml.</p>
|
||||
|
||||
@ -160,6 +168,9 @@ href="http://bugs.gnome.org/db/pa/lgnome-xml.html">Gnome bug
|
||||
database:</a>:</p>
|
||||
<ol>
|
||||
<li>provide patches when you find problems</li>
|
||||
<li>provide the diffs when you port libxml to a new platform. They may not
|
||||
be integrated in all cases but help pinpointing portability problems and
|
||||
</li>
|
||||
<li>provice documentation fixes (either as patches to the code comments or
|
||||
as HTML diffs).</li>
|
||||
<li>provide new documentations pieces (translations, examples, etc ...)</li>
|
||||
@ -219,10 +230,30 @@ platform, get in touch with me to upload the package. I will keep them in the
|
||||
|
||||
<h3>CVS only : check the <a
|
||||
href="http://cvs.gnome.org/lxr/source/gnome-xml/ChangeLog">Changelog</a> file
|
||||
for really accurate description</h3>
|
||||
for a really accurate description</h3>
|
||||
<ul>
|
||||
<li>working on HTML and XML links recognition layers, get in touch with me
|
||||
if you want to test those.</li>
|
||||
<li>XPointer implementation and testsuite</li>
|
||||
<li>Lot of XPath fixes, added variable and functions registration, more
|
||||
tests</li>
|
||||
<li>Portability fixes, lots of enhancements toward an easy Windows build and
|
||||
release</li>
|
||||
<li>Late validation fixes</li>
|
||||
<li>Integrated a lot of contributed patches</li>
|
||||
<li>added memory management docs</li>
|
||||
</ul>
|
||||
|
||||
<p>Item floating around but not actively worked on, get in touch with me if
|
||||
you want to test those</p>
|
||||
<ul>
|
||||
<li>working on HTML and XML links recognition layers</li>
|
||||
<li>parsing/import of Docbook SGML docs</li>
|
||||
</ul>
|
||||
|
||||
<h3>2.2.4: Oct 1 2000:</h3>
|
||||
<ul>
|
||||
<li>main XPath problem fixed</li>
|
||||
<li>Integrated portability patches for Windows</li>
|
||||
<li>Serious bug fixes on the URI and HTML code</li>
|
||||
</ul>
|
||||
|
||||
<h3>2.2.3: Sep 17 2000</h3>
|
||||
@ -1308,6 +1339,6 @@ Gnome CVS base under gnome-xml/example</p>
|
||||
|
||||
<p><a href="mailto:Daniel.Veillard@w3.org">Daniel Veillard</a></p>
|
||||
|
||||
<p>$Id: xml.html,v 1.52 2000/09/17 16:38:14 veillard Exp $</p>
|
||||
<p>$Id: xml.html,v 1.53 2000/09/29 02:42:04 veillard Exp $</p>
|
||||
</body>
|
||||
</html>
|
||||
|
160
doc/xmlmem.html
Normal file
160
doc/xmlmem.html
Normal file
@ -0,0 +1,160 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
||||
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<title>Libxml memory management</title>
|
||||
<meta name="GENERATOR" content="amaya V3.2">
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<h1 align="center">Libxml memory management</h1>
|
||||
|
||||
<p>Location: <a
|
||||
href="http://xmlsoft.org/xmlmem.html">http://xmlsoft.org/xmlmem.html</a></p>
|
||||
|
||||
<p>Libxml home page: <a href="http://xmlsoft.org/">http://xmlsoft.org/</a></p>
|
||||
|
||||
<p>Mailing-list archive: <a
|
||||
href="http://xmlsoft.org/messages/">http://xmlsoft.org/messages/</a></p>
|
||||
|
||||
<p>Version: $Revision$</p>
|
||||
|
||||
<p>Table of Content:</p>
|
||||
<ol>
|
||||
<li><a href="#General">General overview</a></li>
|
||||
<li><a href="#setting">Setting libxml set of memory routines</a></li>
|
||||
<li><a href="#cleanup">Cleaning up after parsing</a></li>
|
||||
<li><a href="#Debugging">Debugging routines</a></li>
|
||||
<li><a href="#General">General memory requirements</a></li>
|
||||
</ol>
|
||||
|
||||
<h2><a name="General">General overview</a></h2>
|
||||
|
||||
<p>The module <code><a
|
||||
href="http://xmlsoft.org/html/gnome-xml-xmlmemory.html">xmlmemory.h</a></code>
|
||||
provides the interfaces to the libxml memory system:</p>
|
||||
<ul>
|
||||
<li>libxml does not use the libc memory allocator directly but xmlFree(),
|
||||
xmlMalloc() and xmlRealloc()</li>
|
||||
<li>those routines can be reallocated to a specific set of routine, by
|
||||
default the libc ones i.e. free(), malloc() and realloc()</li>
|
||||
<li>the xmlmemory.c module includes a set of debugging routine</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="setting">Setting libxml set of memory routines</a></h2>
|
||||
|
||||
<p>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:</p>
|
||||
<ul>
|
||||
<li><a href="http://xmlsoft.org/html/gnome-xml-xmlmemory.html">xmlMemGet
|
||||
()</a> which return the current set of functions in use by the parser</li>
|
||||
<li><a
|
||||
href="http://xmlsoft.org/html/gnome-xml-xmlmemory.html">xmlMemSetup()</a>
|
||||
which allow to set up a new set of memory allocation functions</li>
|
||||
</ul>
|
||||
|
||||
<p>Of course a call to xmlMemSetup() should probably be done before calling
|
||||
any other libxml routines (unless you are sure your allocations routines are
|
||||
compatibles).</p>
|
||||
|
||||
<h2><a name="cleanup">Cleaning up after parsing</a></h2>
|
||||
|
||||
<p>Libxml is not stateless, there is a few set of memory structures needing
|
||||
allocation before the parser is fully functionnal (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:</p>
|
||||
<ul>
|
||||
<li><a href="http://xmlsoft.org/html/gnome-xml-parser.html">xmlCleanupParser
|
||||
()</a> 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).</li>
|
||||
<li><a href="http://xmlsoft.org/html/gnome-xml-parser.html">xmlInitParser
|
||||
()</a> is the dual routine allowing to preallocate the parsing state which
|
||||
can be useful for example to avoid initialization reentrancy problems when
|
||||
using libxml in multithreaded applications</li>
|
||||
</ul>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<h2><a name="Debugging">Debugging routines</a></h2>
|
||||
|
||||
<p>When configured using --with-mem-debug flag (off by default), libxml uses a
|
||||
set of memory allocation debugging routineskeeping 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:</p>
|
||||
<ul>
|
||||
<li><a
|
||||
href="http://xmlsoft.org/html/gnome-xml-xmlmemory.html">xmlMallocLoc()</a>
|
||||
<a
|
||||
href="http://xmlsoft.org/html/gnome-xml-xmlmemory.html">xmlReallocLoc()</a>
|
||||
and <a
|
||||
href="http://xmlsoft.org/html/gnome-xml-xmlmemory.html">xmlMemStrdupLoc()</a>
|
||||
are the memory debugging replacement allocation routines</li>
|
||||
<li><a href="http://xmlsoft.org/html/gnome-xml-xmlmemory.html">xmlMemoryDump
|
||||
()</a> dumps all the informations about the allocated memory block lefts
|
||||
in the <code>.memdump</code> file</li>
|
||||
</ul>
|
||||
|
||||
<p> When developping libxml 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 libxml 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!). </p>
|
||||
|
||||
<p>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 reproductible, it is
|
||||
possible to find more easilly:</p>
|
||||
<ol>
|
||||
<li>write down the block number xxxx not allocated</li>
|
||||
<li>export the environement variable XML_MEM_BREAKPOINT=xxxx</li>
|
||||
<li>run the program under a debugger and set a breakpoint on
|
||||
xmlMallocBreakpoint() a specific function called when this precise block
|
||||
is allocated</li>
|
||||
<li>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.</li>
|
||||
</ol>
|
||||
|
||||
<p> I used to use a commercial tool to debug libxml memory problems but after
|
||||
noticing that it was not detecting memory leaks that simple mechanism was used
|
||||
and proved extremely efficient until now.</p>
|
||||
|
||||
<h2><a name="General">General memory requirements</a></h2>
|
||||
|
||||
<p>How much libxml memory require ? It's hard to tell in average it depends of
|
||||
a number of things:</p>
|
||||
<ul>
|
||||
<li>the parser itself should work in a fixed amout 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).</li>
|
||||
<li>If you are generating the DOM tree then memory requirements will grow
|
||||
nearly lineary 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 (exmple 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 </li>
|
||||
<li>If you don't care about the advanced features of libxml like validation,
|
||||
DOM, XPath or XPointer, but really need to work fixed memory requirements,
|
||||
then the SAX interface should be used.</li>
|
||||
</ul>
|
||||
|
||||
<p></p>
|
||||
|
||||
<p><a href="mailto:Daniel.Veillard@w3.org">Daniel Veillard</a></p>
|
||||
|
||||
<p>$Id$</p>
|
||||
</body>
|
||||
</html>
|
Loading…
x
Reference in New Issue
Block a user