Finding leaks

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 when you type dir
• 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).