CODEWITHSUNDEEP
c++memory-leakswindbg
GreyCat
GreyCat

Reputation: 17134

`sizeof` all types in C++ application

Debugging a suspected memory leak in Windows C++ application, I've managed to get heap allocations statistics that looks like that (this is result of !heap -stat -h ... command executed for relevant heap in WinDbg):

size     #blocks     total     ( %) (percent of total busy bytes)
651 686f0 - 293a51f0  (54.65)
260 68701 - f80a260  (20.55)
11c 68705 - 73dc98c  (9.60)
...

From what I know about the application, this indeed looks pretty much like a leak, but given that I'm only working with a dump that has no user stack trace information, I'm stuck to guesswork and other methods.

One thing I can think about is to understand which class or struct these allocations of 0x651 or 0x260 bytes refer to, as these allocations seem to look pretty suspicious. A straightforward approach that I can think of is to list every class/struct listed in my application and get sizeof results for it.

Is there any simple way to do that (i.e. without resorting to manual extraction of structs/classes with some sort of C++ parser (or worse, regexps), and running sizeof on it in a compiler or something similar)?

Upvotes: 1

Views: 202

Answers (1)

Thomas Weller
Thomas Weller

Reputation: 59564

I don't know of a way of listing all types along with all sizes.

However, you can use x (examine symbols) with the /s option to find types that match the size you're interested in.

Example:

0:004> x /d /s 0n28 ole32!*
[...]
00000000`76a06e78 ole32!IViewObject2_StubThunkTable = <function> *[7]
00000000`769d97fc ole32!g_wszInprocHandler16 = wchar_t [14] "InprocHandler"
00000000`76a96194 ole32!g_wszIconReference = wchar_t [14] "IconReference"

So in your case, the command would be

x /s 651 <mydll>!*

or maybe even

x /s 651 *!*

if you don't suspect a specific DLL.

A similar approach would be dt -e -s 0n28 ole32!*, but it doesn't take *!* as an argument.

Unfortunately, it's still possible that there is no such type, because

  • memory was allocated by malloc()
  • it's just a bunch of identical strings or other objects that are allocated dynamically
  • ...

In that case, you might want to try !heap -flt s 651 and have a look at the UserPtr of some of them.

Example:

0:004> !heap -flt s 2268
    _HEAP @ 130000
              HEAP_ENTRY Size Prev Flags            UserPtr UserSize - state
        0000000000131330 0229 0000  [00]   0000000000131360    02268 - (busy)
    _HEAP @ 20000

0:004> db 0000000000131360    L30
00000000`00131360  3d 00 3a 00 3a 00 3d 00-3a 00 3a 00 5c 00 00 00  =.:.:.=.:.:.\...
00000000`00131370  41 00 4c 00 4c 00 55 00-53 00 45 00 52 00 53 00  A.L.L.U.S.E.R.S.
00000000`00131380  50 00 52 00 4f 00 46 00-49 00 4c 00 45 00 3d 00  P.R.O.F.I.L.E.=.

Upvotes: 1

Related Questions