Finding leaks

From Second Life Wiki
Jump to navigation Jump to search

Overview

This page describes a method how to identify memory leaks within the SecondLife viewer using Microsoft's debug memory routines.

Note: Currently it seems that this will only work for VS2003 because Debug builds fail under VS2005 with /MTd (see the comiling section below). If you are using VS2005 and find a solution, please update this Wiki page.

Note: If you have questions, please use the discussion page on this wiki topic.



Identify Leaks


Modifying the source

Download the memory leak patch from [leakdebug.patch] and apply it to the source tree via

  • in a command shell go to the source directory on the level where you see the 'linden' folder
  • run c:\cygwin\bin\patch -p 0 -i leakdebug.patch


Compiling

The patch activates the leak debugging routines through the linden_common.h files and is only activated in the Debug configuration.

When compiling, make sure you compile all projects with the /MTd flag

  • Set all projects to /MTd
    1. select the Debug configuration from the toolbar
    2. mark all projects in the source tree, except script_compile_fb, test, win_crash_logger and win_updater
    3. select Properties and make sure the Debug configuration is selected in the upper right corner
    4. select C/C++, Language and set Runtime Library to Multithreaded Debug /MTd
    5. close the dialog
  • Add crtdebug.cpp to newview
    1. in the source tree under newview right click Source, add existing
    2. crtdebug.cpp
  • Linker options for newview
    1. select newview alone
    2. in Properties, Linker, Input set Ignore Specific Library to msvcrt.lib;msvcrtd.lib;libc.lib;libcd.lib;libcmt.lib
    3. close the dialog
  • Compile
    1. Simply compile the Debug configuration


Running

  • Run the program under the debugger (F5) or standalone (Ctrl+F5)
  • Running in the debugger during startup you will notice a couple of exceptions when freeing memory. Just continue (these seem to come from the mozilla DLLs).
  • If you encounter crash_and_loop situations (when you hit these, you'll know what it means), consider to delete the contents from the crash_and_loop function and replace it with a single __asm int 3; command. This way the debugger will stop with an exception but you will be able to continue.
  • Finish running the program
  • Look at the leaks.log file in the program folder.


Identifying leaking source through leaks.log

Finding leaks is a nice task. Like post mortem debugging in many cases it is puzzle and detective work and the leaks.log file is your forensic evidence.

  • client blocks were allocated through new operations inside the source. Source file and line number will be identified and usually it is not too hard to figure out a program path that bypasses the deletion.
  • normal memory blocks in the leak dump are coming from 3rd party libraries. You'll need creativity to find these (I do it mostly through custom code in crt_alloc_hook in crtdebug.cpp ... see the example there).