Default Win32 project has constant number of memory leaks

Question

INTRODUCTION AND RELEVANT INFORMATION:

The original project I work on has small memory leaks, so I have decided to perform a small test so I can detect what could cause them.

I have created a Win32 project using Visual Studio wizard. I haven't added anything, I have just left it as it was created with the wizard. I have used the tool GDIView ( http://www.nirsoft.net/utils/gdi_handles.html ) to see if there are any inherent GDI leaks.

PROBLEM:

Each time I resize the window, this tool shows that there are +3 regions that my application leaks.

MY EFFORTS TO SOLVE THE PROBLEM:

Since the project was made by the Visual Studio wizard, I have tried to create a simple project from scratch, but the same +3 regions appear.

Reading through some articles on CodeProject about regions I have stumbled upon some demo applications that demonstrate the usage of them.

When I turn on GDIView these applications also leak +3 regions.

All of this is verified when I turn on Task Manager to see if the small memory leak is really occurring-it does occur since the memory slightly rises and stays constant afterwards no matter how many times I resize the window.

I use Microsoft Visual Studio 2008 Express Edition, but the problem was detected when empty project is created in regular Visual Studio 2008 as well.

I work on Windows XP, but the same effect happens on Windows 7.

QUESTION:

Why is this happening and how to eliminate these small memory leaks?

Thank you.

Best regards.

Answer 1

This is not really something to worry about in terms of being an actual leak, as it probably isn't (i.e., a false-positive). The real problem is that this compromises your ability to diagnose your own memory leaks, as they could get "lost" with these false-positives.

Why is this happening?

This kind of "leak" is quite common. I usually work with Qt + Linux (KDE) for GUI applications, and I see very similar "leaks" all the time. The problem is that within any GUI software, you will have at least these layers: your application, the GUI library, the OS "kernel" libraries, and the graphics drivers. In my experience, most of the reported "leaks" come from the graphics driver, presumably because that kind of low-level code requires a number of "hacks" that can be seen or detected as memory leaks by typical memory diagnostic tools like Valgrind (or whatever you are using). A similar argument can be made with OS kernel code, although in my experience there are much fewer "leaks" coming out of there (I'm think they might be putting a bit more effort into avoiding these "hacks"). In GUI libraries (Qt, Win32 API, etc.), there are often similar "leaks" too, for similar reasons. It is, of course, not excluded that there could be an actual leak in any of those layers, but you have to work under the presumption that there is none, and the fact that the memory consumption stabilizes after some time indicates that it probably is no real leak, at least, not any that could do damage (like runaway memory consumption) (btw, this behavior of memory consumption that increases and then stabilizes is perfectly normal, it has to do with heap-fragmentation that grows and eventually reaches equilibrium).

how to eliminate these small memory leaks?

You can't really eliminate those leaks, especially if you really don't have anything to do with them (i.e., they are coming out of the GUI library stack, not from your application). The best you could do is report those diagnostics to whoever is in charge of support and maintenance of those libraries (e.g., Microsoft), but it is likely to be ignored or deemed to be a normal occurrence (not really a leak).

Now, to the real problem, if you want to diagnose your own potential memory leaks, then you will have to find a systematic way to circumvent or ignore the "leaks" coming from the GUI library stack. Here are a few typical solutions:

1. Check for leaks often and avoid doing the things (e.g., resizing) that increases the number of false-positives. Learn to "know your leaks" in the sense that by checking often, you will become familiar with the leaks that come out of the GUI library stack, and be able to ignore them or "subtract" them from the diagnostics and only see the real leaks.
2. Use filtering tools to filter the output of your memory diagnostic tool. Most tools to check for leaks will have filtering options to filter out (or to silence) warnings or errors coming out of certain libraries or functions. You can use those to silence the false leaks detected in these third-party libraries. But be careful not to filter too much (e.g., like filtering out all leaks coming from the CRT), you should remain conservative (you can even introduce deliberate memory leaks in your code to check that they don't get filtered out).
3. Modularize your application such that most of the important code (the heavy-lifting code) can be run in a simpler command-line program. In other words, make the GUI into a simple front-end (which is easy to make leak-free) that uses some heavy-lifting back-end code. You can transplant that back-end code into a much simpler command-line program, and thus, avoiding the GUI library stack completely and allowing you to check for memory leaks more effectively, without all the "pollution". This is the recommended solution for any serious project, and it also fosters good coding practices (unit-testing, modularized code, minimal inter-dependencies, etc.).