5

I am using _CrtDumpMemoryLeaks to identify memory leaks in our software. We are using a third party library in a multi-threaded application. This library does have memory leaks and therefore in our tests we want to identify those that ours and discard those we do not have any control over.

We use continuous integration so new functions/algorithms/bug fixes get added all the time.

So the question is - is there a safe way of identifying those leaks that are ours and those that are the third parties library. We though about using allocation numbers but is that safe?

Ed Heal
  • 59,252
  • 17
  • 87
  • 127
  • Forgot to add we have COM and the use of both Intel and Visual Studio compiler into the mix – Ed Heal Aug 03 '14 at 11:11
  • Allocation numbers are assigned by a global variable. With multi-threading, the allocation numbers become unpredictable. – brian beuning Aug 06 '14 at 10:32
  • I wouldn't recommend changing your code in order to gather such information. Why don't you use a profiler instead? I have been using Compuware Devpartner in the past and it showed me exactly where the memory leaks originated. There's probably other (free) profiling solutions out there that will achieve the same. Perhaps one of these: http://stackoverflow.com/questions/67554/whats-the-best-free-c-profiler-for-windows – Alexander Tobias Bockstaller Aug 10 '14 at 11:32

5 Answers5

5

In a big application I worked on the global new and delete operators were overwritten (eg. see How to properly replace global new & delete operators) and used private heaps (eg. HeapCreate). Third party libraries would use the process heap and thus the allocation would be clearly separated.

Frankly I don't think you can get far with allocation numbers. Using explicit separate heaps for app/libraries (and maybe even have separate per-component heaps within your own app) would be much more manageable. Consider that you can add your own app specific header to each allocated block and thus enable very fancy memory tracking. For example capture the allocation entire call-stack would be possible, for debugging. Enable per-component accounting. Etc etc.

Community
  • 1
  • 1
Remus Rusanu
  • 288,378
  • 40
  • 442
  • 569
2

You might be able to do this using Mirosoft's heap debugging library without using any third-party solutions. Based on what I learned from a previous question here, you should just make sure that all memory allocated in your code is allocated through a call to _malloc_dbg where the second argument is set to _CLIENT_BLOCK. Then you can set a callback function with _CrtSetDumpClient, and that callback will only receive information about the client blocks that were allocated, not the other ones.

You can easily use the preprocessor to convert all the calls to malloc and free to actually call their debugging versions (e.g. _malloc_dbg); just look at how it's done in crtdbg.h which comes with Visual Studio.

The tricky part for me would be figuring out how to override the new and delete operators to call debugging functions like _malloc_dbg. It might be hard to find a solution where only the news and deletes in your own code are affected, and not in the third-party library.

Community
  • 1
  • 1
David Grayson
  • 84,103
  • 24
  • 152
  • 189
1

The answer would REALLY depend on the actual implementation of the third partly library. Does it only leak a consistent number of items, or does that depend on, for example, the number of threads, what functions are used within the library, or some such? When are the allocations made?

Even then if it's a consistent number of leaks regardless of library usage, I'd be hesitant to use this the allocation number. By all means, give it a try. If all the allocations are made very early on, and they don't depend on any of "your" code, then it could work - and it is a REALLY simple thing. But try adding for example a static std::vector<int>(100) to see if memory allocations in static variables are affecting the allocation number... If it does, this method is probably doomed (unless you have very strict rules on static objects).

Using a separate heap (with new/delete operators replaced) would be the correct solution, as this can probably be expanded to gather other statistics too [like number of allocations made, to detect parts of the code that makes excessive allocations - of course, this has to be analysed based on what the code actually does].

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • We have a feeling that the leaks are due to static variables. The number of leaks appear to be consistent. I will explore your suggestions futher – Ed Heal Aug 03 '14 at 11:09
1

You may want to use DebugDiag Tool provided by Microsoft. For complete information about the tool we can refer : http://www.microsoft.com/en-sg/download/details.aspx?id=40336

DebugDiag can be used for identifying various issue. We can follow the steps to track down the leaks(ours and third party module):

  1. Configure the DebugDiag under Rule Type "Native(non .NET) Memory and Handle Leak".
  2. Now Re-run the application for sometime and capture the dump files. We can also configure the DebugDiag to capture the dump file after specified interval.
  3. Now we can open/analyze the captured dump file using DebugDiag under the "Performance Analyzers".

Once analysis is complete, DebugDiag would automatically generate the report and would give you the modules/DLL information where leak is possible(with probability). After this we get the information about the modules from DebugDiag tool, we can concentrate on that particular module by doing static code analysis. If modules belongs to third party DLL, we can share the DebugDiag report to them. In addition to this, if you run/attach your application with appropriate PDB file, DebugDiag also provides the call stack from where chances of memory leak is possible.

These information were very useful in the past while debugging memory leak on windows based application. Hopefully above information would be useful.

Mantosh Kumar
  • 5,659
  • 3
  • 24
  • 48
1

The newer Doug Lea malloc's include the mspace abstraction. An mspace is a separate heap. In our couple 100K NCSL application, we use a dozen different mspace's for different parts of the code. We use allocators to have STL containers allocate memory from the right mspace.

Some of the benefits

  • 3rd party code does not use mspaces, so their allocation (and leaks) do not mix with ours
  • We can look at the memory usage of each mspace to see which piece of code might have memory leaks
  • Any memory corruption is contained within one mspace thus limiting the amount of code we need to look at for debugging.
brian beuning
  • 2,836
  • 18
  • 22