Load /tmp/libxml2-2.6.32 intoupstream/2.6.32.dfsg

libxml2/branches/upstream/current.

1 files changed, 63 insertions, 9 deletions

diff --git a/doc/xml.html b/doc/xml.html
index 355dbed..8e42443 100644
--- a/doc/xml.html
+++ b/doc/xml.html
@@ -739,6 +739,43 @@ to the <a href="http://svn.gnome.org/viewcvs/libxml2/trunk/">SVN</a> code base.<
 
 <p>Here is the list of public releases:</p>
 
+<h3>2.6.32: Apr 8 2008</h3>
+<ul>
+  <li>Documentation: returning heap memory to kernel (Wolfram Sang),
+      trying to clarify xmlCleanupParser() use, xmlXPathContext improvement
+      (Jack Jansen), improve the *Recover* functions documentation,
+      XmlNodeType doc link fix (Martijn Arts)</li>
+  <li>Bug fixes: internal subset memory leak (Ashwin), avoid problem with
+      paths starting with // (Petr Sumbera), streaming XSD validation callback
+      patches (Ashwin), fix redirection on port other than 80 (William Brack),
+      SAX2 leak (Ashwin), XInclude fragment of own document (Chris Ryan),
+      regexp bug with '.' (Andrew Tosh), flush the writer at the end of the
+      document (Alfred Mickautsch), output I/O bug fix (William Brack),
+      writer CDATA output after a text node (Alex Khesin), UTF-16 encoding
+      detection (William Brack), fix handling of empty CDATA nodes for Safari
+      team, python binding problem with namespace nodes, improve HTML parsing
+      (Arnold Hendriks), regexp automata build bug, memory leak fix (Vasily
+      Chekalkin), XSD test crash, weird system parameter entity parsing problem,
+      allow save to file:///X:/ windows paths, various attribute normalisation
+      problems, externalSubsetSplit fix (Ashwin), attribute redefinition in
+      the DTD (Ashwin), fix in char ref parsing check (Alex Khesin), many
+      out of memory handling fixes (Ashwin), XPath out of memory handling fixes
+      (Alvaro Herrera), various realloc problems (Ashwin), UCS4 encoding
+      conversion buffer size (Christian Fruth), problems with EatName
+      functions on memory errors, BOM handling in external parsed entities
+      (Mark Rowe)</li>
+  <li>Code cleanup: fix build under VS 2008 (David Wimsey), remove useless
+      mutex in xmlDict (Florent Guilian), Mingw32 compilation fix (Carlo
+      Bramini), Win and MacOS EOL cleanups (Florent Guiliani), iconv need
+      a const detection (Roumen Petrov), simplify xmlSetProp (Julien Charbon),
+      cross compilation fixes for Mingw (Roumen Petrov), SCO Openserver build
+      fix (Florent Guiliani), iconv uses const on Win32 (Rob Richards),
+      duplicate code removal (Ashwin), missing malloc test and error reports
+      (Ashwin), VMS makefile fix (Tycho Hilhorst)</li>
+  <li>improvements: better plug of schematron in the normal error handling
+      (Tobias Minich)</li>
+</ul>
+
 <h3>2.6.31: Jan 11 2008</h3>
 <ul>
   <li>Security fix: missing of checks in UTF-8 parsing</li>
@@ -3356,9 +3393,10 @@ should be both simple and complete enough to allow you to build your own.</p>
 <ol>
   <li><a href="#General3">General overview</a></li>
   <li><a href="#setting">Setting libxml2 set of memory routines</a></li>
-  <li><a href="#cleanup">Cleaning up after parsing</a></li>
+  <li><a href="#cleanup">Cleaning up after using the library</a></li>
   <li><a href="#Debugging">Debugging routines</a></li>
   <li><a href="#General4">General memory requirements</a></li>
+  <li><a href="#Compacting">Returning memory to the kernel</a></li>
 </ol>
 
 <h3><a name="General3">General overview</a></h3>
@@ -3391,27 +3429,29 @@ debugging, analysis or to implement a specific behaviour on memory management
 any other libxml2 routines (unless you are sure your allocations routines are
 compatibles).</p>
 
-<h3><a name="cleanup">Cleaning up after parsing</a></h3>
+<h3><a name="cleanup">Cleaning up after using the library</a></h3>
 
 <p>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:</p>
+reuse the library or any document built with it:</p>
 <ul>
   <li><a href="http://xmlsoft.org/html/libxml-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>
+    ()</a> is a centralized routine to free the library state and data. Note
+    that it won't deallocate any produced tree if any (use the xmlFreeDoc()
+    and related routines for this). This should be called only when the library
+    is not used anymore.</li>
   <li><a href="http://xmlsoft.org/html/libxml-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 libxml2 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>
+<p>Generally xmlCleanupParser() is safe assuming no parsing is ongoing and
+no document is still being used, if needed the state will be rebuild at the
+next invocation of parser routines (or by xmlInitParser()), but be careful
+of the consequences in multithreaded applications.</p>
 
 <h3><a name="Debugging">Debugging routines</a></h3>
 
@@ -3497,6 +3537,20 @@ of a number of things:</p>
 </ul>
 
 <p></p>
+<h3><a name="Compacting">Returning memory to the kernel</a></h3>
+
+<p>You may encounter that your process using libxml2 does not have a
+reduced memory usage although you freed the trees. This is because
+libxml2 allocates memory in a number of small chunks. When freeing one
+of those chunks, the OS may decide that giving this little memory back
+to the kernel will cause too much overhead and delay the operation. As
+all chunks are this small, they get actually freed but not returned to
+the kernel. On systems using glibc, there is a function call
+"malloc_trim" from malloc.h which does this missing operation (note that
+it is allowed to fail). Thus, after freeing your tree you may simply try
+"malloc_trim(0);" to really get the memory back. If your OS does not
+provide malloc_trim, try searching for a similar function.</p>
+<p></p>
 
 <h2><a name="Encodings">Encodings support</a></h2>