From c2c9a9c0b6e0b41b12883984ca37b8ae63ba2adc Mon Sep 17 00:00:00 2001 From: "kipp%netscape.com" Date: Mon, 11 Oct 1999 15:30:17 +0000 Subject: [PATCH] Updated documentation to be more accurate; provided description of command line arguments git-svn-id: svn://10.0.0.236/trunk@50340 18797224-902f-48f8-a5cc-f745e15eee43 --- mozilla/tools/leaky/leaky.html | 250 ++++++++++++++++++++++----------- 1 file changed, 165 insertions(+), 85 deletions(-) diff --git a/mozilla/tools/leaky/leaky.html b/mozilla/tools/leaky/leaky.html index ec91b2a715c..3cb8ca6a546 100644 --- a/mozilla/tools/leaky/leaky.html +++ b/mozilla/tools/leaky/leaky.html @@ -1,55 +1,38 @@ -Leaky + + + Leaky -
-Leaky -

-Leaky is a program which will help you find memory leaks, and as of late, -help you debug reference count problems with xpcom objects.
-
+
Leaky
- -Get the Source -
-Leaky is not currently part of the default SeaMonkey module,
-you will need to explicitly pull the source:
-
-
-  cvs checkout mozilla/tools/leaky
-
-If there is enough demand, we can make this part of -the default SeaMonkey module. -
-
- - -Building it -
-
-  ./configure --enable-leaky
-
+

Leaky is a program which will help you find memory leaks, and as of +late, help you debug reference count problems with xpcom objects. +

Get the Source +

Leaky is not currently part of the default SeaMonkey module, +
you will need to explicitly pull the source: +
  +

  cvs checkout mozilla/tools/leaky
+If there is enough demand, we can make this part of the default SeaMonkey +module. +

Building it +
  +

  ./configure --enable-leaky
Top-of-tree build should Just Build It and leaky will show up in dist/bin. -
-
- - - -Using Leaky -
- -After it has been built, you can use TestPreload and TestMalloc and ShowLibs to -debug your implementation. -

By setting the LIBMALLOC_LOG environment variable you control how much -information is logged during the programs execution. See libmalloc.h for -a definition of the values to use. If you are using LD_PRELOAD, here is -one way to run your program: +

Using Leaky +

After it has been built, you can use TestPreload and TestMalloc and +ShowLibs to debug your implementation. +

By setting the LIBMALLOC_LOG environment variable you control +how much information is logged during the programs execution. See libmalloc.h +for a definition of the values to use. If you are using LD_PRELOAD, +here is one way to run your program:

env LD_PRELOAD=/full/path/to/libleaky.so LIBMALLOC_LOG=1 my-program
-The debugging malloc library creates two files, malloc-log and malloc-map. +The debugging malloc library creates two files, malloc-log and +malloc-map. The malloc-log file can be quite large for large programs (e.g. mozilla) so be prepared to have alot of disk space. The malloc-map is tiny.

Once your program has completed execution you can use leaky to look @@ -60,15 +43,20 @@ Leaky will then display all of the call sites where memory was leaked. To look at the entire log file contents, not just the leaks add "-a" to the arguments:

leaky -d -a <program-name-goes-here> malloc-log
-For debugging reference count issues, here is what I do: +For debugging reference count issues, here is what I do:
  1. -Set LIBMALLOC_LOG to "8"
    2. +Set LIBMALLOC_LOG to "8"
  2. Modify your source code so that your class::Addref and class::Release methods call __log_addref and __log_release, as appropriate. See libmalloc.h for -their signatures.
    3. +their signatures. If you are using mozilla, you no longer need to modify +your source code with a debug build. See + +xpcom/doc/MemoryTools.html for more info. + +
  3. Run your program so that you get the log data. Its often convenient to @@ -77,68 +65,160 @@ location where you think some object is being leaked or over-freed. Then when the debugger gets there tell it to execute DumpAddressMap. In gdb you do this:
    4. -
        -
      (gdb) p DumpAddressMap() -
       
    +
        +
      (gdb) p DumpAddressMap()
  4. Then use leaky to capture the addref and release calls to a log file:
      5.   -
      leaky -d -a <program-name-goes-here> malloc-log > log -
       
    +
    leaky -d -a <program-name-goes-here> malloc-log > log
  • Then use "grep" to search the log for a specific object by grepping for its memory address...
  • -On a typical *short* run of mozilla, I'll end up with a malloc-log -file of around 5 to 10 megabytes and the resulting converted log file will -be 10 to 20 times that so be prepared to have alot of disk space. It helps +On a typical *short* run of mozilla, I'll end up with a malloc-log file +of around 5 to 10 megabytes and the resulting converted log file will be +10 to 20 times that so be prepared to have alot of disk space. It helps a great deal to narrow down your problem space to reduce the log file size...
    • -
    -Leaky now has a "graph" output option. If you do this:

    -
    -  leaky -gqx <program-name-goes-here>  malloc-log | c++filt | sed -e 's/&/&/g' > /tmp/GQ0.html
    -

    Then leaky will make a graph of the leaks [-g] and output that graph -in xml format (currently actually html...) [-x]. I use c++filt to -translate the C++ mangled names into ascii and then use sed to make it -legitimate html and off it goes to a file.

    +


    Leaky now has a "graph" output option. If you do this: +

      leaky -gqx <program-name-goes-here>  malloc-log | sed -e 's/&/&/g' > /tmp/GQ0.html
    +Then leaky will make a graph of the leaks [-g] and output that graph in +xml format (currently actually html...) [-x]. I use sed to make it legitimate +html and off it goes to a file. +

    If you throw file at viewer (recursion is cool) then it will present +you with a treeview of the leaks that you can click on to open/close sections. +Enjoy! +

    Command Line Options +
      + + + -

    If you throw file at viewer (recursion is cool) then it will -present you with a treeview of the leaks that you can click on to -open/close sections. Enjoy!

    + + -
    -
    + + - -Porting to non-Intel/Linux -
    + + -

    Initial version works only on x86 linux. To work on other platforms you will need to: +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    -adump the entire log. This means all malloc's, free's, new's, delete's, +addref's or release's will be displayed
    -ddump leaks (only one of -d, -R or -g can be used at a time)
    -Rdump refcnts
      
    -gdisplay a graph of leaks
    -xwhen displaying the graph with -g, use html output that can be fed +into an html4+css+dom compliant viewer (like mozilla :-)
    -r symboldefine a root for the graph dump. nodes in the graph above symbol will +be hidden, thus reducing the depth of the graph making it easier to find +deeper leaks.
      
    -e symbolexclude leaks that include symbol from treatment
    -i symbolinclude leaks that include symbol for treatment. If an includes are +defined than only leaks which include the symbols will be processed. excludes +will still apply to this reduced set of leaks
      
    -Ashow the address in the stack crawls, not just the symobls
    -h numset the size of the hash buckets used by leaksy dictionaries to <num>
    -s depthset the depth of the stack crawls shown when displaying stack crawls +(any of the dumping modes except -g)
    -qmake leaky quiet (don't dump the information about symbols being read +and from which libraries)
    + +

    Porting to non-Intel/Linux +
      +

    Initial version works only on x86 linux. To work on other platforms +you will need to:

      -
    1. Implement CrawlStack() in libmalloc.cpp
      2. -
    2. Implement DumpAddressMap() in libmalloc.cpp and in ShowLibs.cpp
      3. -
    3. Either support LD_PRELOAD in your dynamic linker, or
      produce a library -that wraps your libc malloc (see config.h for some clues)
      4. -
    4. Implement symbol table reading code (see coff.cpp, elf.cpp and bfd.cpp +
    5. +Implement CrawlStack() in libmalloc.cpp
      6. + +
    6. +Implement DumpAddressMap() in libmalloc.cpp and in ShowLibs.cpp
      7. + +
    7. +Either support LD_PRELOAD in your dynamic linker, or
      8. + +
      produce a library that wraps your libc malloc (see config.h for some +clues) +
    8. +Implement symbol table reading code (see coff.cpp, elf.cpp and bfd.cpp for examples; at the time of writing this document only bfd.cpp was known to work)
    -
    - -Last modified: Sun Sep 26 13:15:33 PDT 1999 - -
    -Send comments to Kipp Hickman
    -
    - - - +
    Last modified: Sun Sep 26 13:15:33 PDT 1999 +
    Send comments to Kipp Hickman +