views:

161

answers:

2

Hello all! I've got stuck in a problem with gflags when trying to find some memory leaks in a windows app.

When I turn on the ust flag (in order to collect memory allocations stack traces) the memory of my application increases much faster than it does when the flag is off (it reaches to 800MB in 10 min aprox. which is far from the 50-100MB/day I get when the flag is off).

I've read that there is a maximum for stack traces of 32MB, so I suppose this shouldn't be a problem.

The computer is a 4x Intel(R) Xeon(R) CPU E5410 @ 2.33GHz.

If someone could give me some hint I'd really appreciate it.

Thank you!

A: 

You can set the maximum trace database size using /tracedb SizeInMB See the MSDN Gflags documentation for chapter and verse. By default there is no maximum size which most likely explains the bahaviour you have seen.

Paul Arnold
I've taken a look at the documentation and it says: "The default value is the minimum size, 8 MB; there is no maximum size." I think this means that there IS a default size equal to the minimum (8MB), isn't it?Anyway, thank you for you answer!
David Alfonso
+2  A: 

The stack trace database is not the only impact of the ust flag. It also adds at least 32 bytes to each allocation, in order to store its stack trace id. This could explain your memory increase if lots of small allocations are involved. If you launch the process with an attached debugger or compiled the process with debug target, the windows heaps will be set in debug mode and the overhead per allocation will be even bigger.

plodoc
Thank you plodoc, then what would you propose to do in order to find the memory leaks?
David Alfonso
You may try !heap -stat command and !heap -flt windbg commands. !heap -stat will list the heaps by reverse order of size. Look at the first ones with !heap -stat -h <heap handle> to get the category of object size that uses the most space. Then !heap -flt s <size> will list all the objects of this size. Look into these object to see if you can identify them.
plodoc