1
0
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:
Daniel Veillard 2000-10-13 10:23:06 +00:00
parent 2f971a26da
commit 189446d2fa
4 changed files with 213 additions and 18 deletions

View File

@ -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

View File

@ -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

View File

@ -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
View 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>