1

I have a simple C++ Service which reads text from a file and sends it over the Network. Over time the memory consumption of this service increases at customer site. No such behavior is observed in QA testing.

I would like to know if it is possible to extract all the String Objects that are in the memory at any given time.

Will it be possible to automate this process such that I take dumps from customer at different times and find out sizes or contents of the memory at each time and compare the results.

Geek
  • 23,089
  • 20
  • 71
  • 85

3 Answers3

3

For c++ the answer is no (In C# is a different story). In the c++ world, if you suspect you have a leak you would want to enable usermode stack tracing (+ust in gflags.exe) on the process before the "leak" occurs. The after the leak has occurred, get a dump of the process and examine it. To examine it (I have assumed you are using the native windows heap in this response), you will want to walk throught he heap structures to find out where the allocations are, then examine the stack backtrace for a sampling of the most common allocation size.

Example.

  1. Before you apps is running, run gflags /i MyApp.exe +ust. This sets up the regkey that provides the OS the special instructions for how to handle the process MyApp.exe
  2. Run the program and let the "bad behavior" occur
  3. Collect a dump of the process while the bad behavior is easy to see (the easier it is to see, the easier it will be to find)
  4. Open the dump in Windbg
  5. !heap -summary and find the heap with the larges Virtual Byte count
  6. The first colomn is your heap handle. Use the heap handle from the entry you found in the previous step and run !heap -stat -h -grp. This will list the heap allocations that are using the most space in the given heap.
  7. So we now know which heap was large, and the size of the entries that are the most common. We know need the address of a few so we can look at the call stack that allocated them. Run !heap -flt s .
  8. Last step (we are sooo close). Run !heap -p -a . You will now have the stack backtrace for what codepath generated this allocation. Now you can go back to your code and find out why this is not getting freed.
JasonE
  • 894
  • 6
  • 8
1

It sounds like you have a memory leak. I only uses windbg to debug managed applications. Maybe this Link can help you a bit.

Community
  • 1
  • 1
mslot
  • 4,959
  • 9
  • 44
  • 76
  • Yeah friend, it looks like a leak that happens only in customer environment. Thanks for the link it has useful information. – Geek Dec 12 '11 at 09:07
1

http://msdn.microsoft.com/en-us/library/ff558947(v=vs.85).aspx is your best bet for what you want to do.

Ana Betts
  • 73,868
  • 16
  • 141
  • 209
  • 1
    UMDH consumes the data created by +ust. The downside is that you have to have symbols setup on the target machine. This is the main reason I just grab the dump, move it to my tools machine and look at the data there. – JasonE Dec 13 '11 at 12:22
  • That is one tricky part, yeah - same thing applies with ETL, you have to have copies of the target machine's binaries to do matching, and UMDH doesn't record the checksum information to look it up – Ana Betts Dec 13 '11 at 21:16