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. It should be completely transparent in other configurations like ReleaseNoOpt or ReleaseForDownload.

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).