Windows Leaks Detector

 

Introduction
Memory Leaks - Different Approach
Current Limitations
Articles
Future directions
Download

Back to Summary page

 

Introduction

Windows Leaks Detector is a tool for easy detection of memory leaks in any Windows application. Main features:

• No modifications in source code. Actually the code is not required.
• Works for any Windows application written in any language.
• Attaching to any running process.
• Especially effective for applications working in “cyclic” patterns.
• Aggregation of memory leaks by call stack.

 

 

Memory Leaks - Different Approach

 

What is "memory leak"? Usually we mean "a block of memory that was allocated by the program, and was not released”. To be more precise: “… and was not released before the program ended”.

 

I think this definition is not appropriate for many applications. First let’s remember that when a program ends, all the memory that was allocated by it is automatically released by OS. So it will not make much difference if the memory was released by the process just before the termination. The more interesting parameter, especially for long-running programs, is the change in memory consumption in time. As simplest example we can look at programs that work in “cyclic” patterns. Here “cycle” refers to unit of work, after which the process should return to the state in which it was before the “cycle” started. For instance: text editor which opens and works with a document, and then closes it; a service which processes single request. In all those cases we can talk about “memory leak per cycle”. In case such memory leak exists, even if relatively small, it can cause serious performance problems over the time.

 

Conclusions that we may get with this approach:

• It is more important to avoid “cyclic” memory leaks, than one-time leaks – O(n) VS O(1).
• Such memory leaks may exist even in programs written in languages featuring automatic garbage collection. For example, in VB you can continuously create new objects, and add them to some Collection, so you will always have live reference to object.

 

Prior to selecting the right tool for hunting cyclic memory leaks, let’s think what additional important characteristics we would like it to have. Let’s take text editor “my_edit.exe” application as example. I would like to perform following steps:

1.      run “my_edit.exe”

2.      open existing document, add new line, save changes and close the document

3.      start monitoring memory allocations

4.      repeat step 2

5.      stop monitoring memory allocations

6.      repeat step 2

7.      report: all memory allocations done in step 6, which was not released in steps 6-8

 

Here I would like to explain some of the steps in more details:

Step 2: before starting memory monitoring, I want to make sure the application is fully initialized. It’s possible there will be some one-time allocations while opening the first document.

Step 6: here I let the application a chance to do full cleanup of memory allocated in step 4. There may be, for example, some objects remaining in memory after step 4, which will be released only when next document is processed.

 

Given scenario implies following features of memory monitoring tool:

1. it should be able to begin the monitoring at some point in time
2. it should be able to stop registering new allocations, but still watch memory being released

 

I can extend this “wish list” with additional features, which will make my work much easier:

1. for each memory allocation I want to know the full call stack
2. moreover, I would like all memory leaks to be aggregated by the call stack
3. I don’t want to do any change in my application
4. I may not even have the source code, and still want to discover memory leaks
5. the tool should be able to attach to any running application
6. I may want to activate a breakpoint each time a memory allocation is done from “leaking” call stack, in order to attach the debugger in right position

 

Well, that’s what Windows Leaks Detector is designed for.

 

 

Current Limitations

 

• The solution only monitors HeapAlloc, HealRealloc and HealFree functions. In future additional memory-related functions should be traced, e.g. HeapCreate function, so the solution will work correctly also for applications which create and release heaps dynamically.
• You can’t monitor 2 processes at the same time – the mechanism of inter-process communication should be redesigned.

 

Articles

Prove Of Concept - Detection of out-of-bounds memory accesses.

 

 

Future directions

 

The main task is to support detection of leaks in other resources, besides the memory – such as unclosed File Handles