From a7e9d3f37d5e9fba4b9acaa43e7c12b6d9a669ae Mon Sep 17 00:00:00 2001 From: Mike Hommey Date: Thu, 8 Jun 2006 10:59:26 +0200 Subject: Load /tmp/libxml2-2.6.26 into libxml2/branches/upstream/current. --- doc/xmlmem.html | 166 ++++++++++++++++++++++++++++---------------------------- 1 file changed, 83 insertions(+), 83 deletions(-) (limited to 'doc/xmlmem.html') diff --git a/doc/xmlmem.html b/doc/xmlmem.html index 58c2987..40dc4cb 100644 --- a/doc/xmlmem.html +++ b/doc/xmlmem.html @@ -12,91 +12,91 @@ A:link, A:visited, A:active { text-decoration: underline }
  • Cleaning up after parsing
  • Debugging routines
  • General memory requirements
    • -

    General overview

    The module xmlmemory.h -provides the interfaces to the libxml2 memory system:

    Setting libxml2 set of memory routines

    It is sometimes useful to not use the default memory allocator, +eitherfordebugging, analysis or to implement a specific behaviour on +memorymanagement(like on embedded systems). Two function calls are available +to doso:

    Of course a call to xmlMemSetup() should probably be done beforecallingany +other libxml2 routines (unless you are sure your allocationsroutines +arecompatibles).

    Cleaning up after parsing

    Libxml2 is not stateless, there is a few set of memory +structuresneedingallocation before the parser is fully functional (some +encodingstructuresfor example). This also mean that once parsing is finished +there isa tinyamount of memory (a few hundred bytes) which can be recollected +if youdon'treuse the parser immediately:

    Generally xmlCleanupParser() is safe, if needed the state will berebuildat +the next invocation of parser routines, but be careful of theconsequencesin +multithreaded applications.

    Debugging routines

    When configured using --with-mem-debug flag (off by default), libxml2usesa +set of memory allocation debugging routines keeping track of +allallocatedblocks and the location in the code where the routine was called. +Acouple ofother debugging routines allow to dump the memory allocated infos +toa fileor call a specific routine when a given block number is allocated:

    When developing libxml2 memory debug is enabled, the tests +programscallxmlMemoryDump () and the "make test" regression tests will check +foranymemory leak during the full regression test sequence, this helps +alotensuring that libxml2 does not leak memory and bullet +proofmemoryallocations use (some libc implementations are known to be far +toopermissiveresulting in major portability problems!).

    If the .memdump reports a leak, it displays the allocation functionandalso +tries to give some informations about the content and structure +oftheallocated blocks left. This is sufficient in most cases to find +theculprit,but not always. Assuming the allocation problem is reproducible, +itispossible to find more easily:

    1. write down the block number xxxx not allocated
      2. +
    2. export the environment variable XML_MEM_BREAKPOINT=xxxx , + theeasiestwhen using GDB is to simply give the command

      set environment XML_MEM_BREAKPOINT xxxx

      before running the program.

      3. -
    3. run the program under a debugger and set a breakpoint on - xmlMallocBreakpoint() a specific function called when this precise block - is allocated
      4. -
    4. 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.
      5. -

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