Re: windbg digest: April 13, 2016

As far as I know, once the heap grows, even if you release all the memory
blocks, it never releases its managed (previously allocated) memory back to
the OS.

This is true for allocations below ~512Kb (32 bits)/~1024Kb (64 bits) or
so, which are managed by the heap.

Larger allocations do go back to the OS, since they are made using a single
VirtualAlloc() call for that allocation, and followed by a VirtualFree()
when that memory block is freed.

You can see this in the documentation for RltCreateHeap().

Also, the heap grows by doubling its size when an allocation can not be
doled out from the free memory blocks available. The growth pattern goes
like this:

If you mark your 32 bit image to be Large Address Aware and have a start
heap of 1Mb, this is the growth progression for the heap size (in
separately managed chunks):
1Mb, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1Gb, (all these are contiguous).
After these, it will try to get another 512Mb each time it needs more, but
that memory can be in non-contiguous chunks (e.g. 128Mb+256Mb+64Mb+64Mb) as
the free virtual address map permits.

On Wed, Apr 13, 2016 at 11:59 PM Kernel Debugging Interest List digest <
xxxxx@lists.osr.com> wrote:

WINDBG Digest for Wednesday, April 13, 2016.

  1. heap leak: confused about !heap -stat result

Subject: heap leak: confused about !heap -stat result
From: xxxxx@sina.com
Date: Wed, 13 Apr 2016 23:19:59 -0400 (EDT)
X-Message-Number: 1

Hi,

I have a x64 user mode program that consumes too much memory in heap. And
I want to find out the root cause. The article here describes a nice way to
do it.

http://www.codeproject.com/Articles/31382/Memory-Leak-Detection-Using-Windbg

Here is my problem. A ā€œ!heap -sā€ output confirms that the program indeed
has a large heap (more than 600MB). But the following ā€œ!heap -stat -h
000000f6df7b0000ā€ shows that the largest blocks only consumes 6401a0 bytes,
67% of the total (which means the total busy bytes are only 9MB).

Can someone explain why the largest memory occupation is only a fraction
of total committed memory in the heap?

Detailed output below:

0:001> !heap -s

************************************************************************************************************************
NT HEAP STATS BELOW

************************************************************************************************************************
NtGlobalFlag enables following debugging aids for new heaps:
stack back traces
LFH Key : 0x5c04e58648294954
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt
Lock Fast
(k) (k) (k) (k) length blocks
cont. heap


000000f6df7b0000 08000002 663988 655200 663884 456 71 45 1
0 LFH
000000f6ddd80000 08008000 64 4 64 2 1 1 0
0
000000f6df9e0000 08001002 164 64 60 1 4 1 0
0 LFH
000000f6e14e0000 08001002 1184 80 1080 19 5 2 0
0 LFH
000000f6e13c0000 08001002 164 28 60 0 2 1 0
0 LFH


0:001> !heap -stat -h 000000f6df7b0000
heap @ 000000f6df7b0000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
c8034 8 - 6401a0 (66.98)
54 2322 - b8728 (7.72)
103 9ca - 9e75e (6.63)
5c 1539 - 7a07c (5.11)
ac 7fb - 55ca4 (3.59)
40 b2c - 2cb00 (1.87)
3c ac8 - 286e0 (1.69)
4c 479 - 153ec (0.89)
6334 3 - 1299c (0.78)
c334 1 - c334 (0.51)
100 c1 - c100 (0.50)
a534 1 - a534 (0.43)
44 137 - 529c (0.22)
30 195 - 4bf0 (0.20)
4a8 f - 45d8 (0.18)
4234 1 - 4234 (0.17)
1034 4 - 40d0 (0.17)
118 32 - 36b0 (0.14)
104c 3 - 30e4 (0.13)
9a0 5 - 3020 (0.13)

=======================
0:001> !heap -stat -h 000000f6df7b0000 -grp B
heap @ 000000f6df7b0000
group-by: BLOCKCOUNT max-display: 20
size #blocks total ( %) (percent of totalblocks)
54 2322 - b8728 (32.66)
5c 1539 - 7a07c (19.73)
40 b2c - 2cb00 (10.39)
3c ac8 - 286e0 (10.02)
103 9ca - 9e75e (9.10)
ac 7fb - 55ca4 (7.42)
4c 479 - 153ec (4.16)
30 195 - 4bf0 (1.47)
44 137 - 529c (1.13)
100 c1 - c100 (0.70)
50 58 - 1b80 (0.32)
20 41 - 820 (0.24)
118 32 - 36b0 (0.18)
74 24 - 1050 (0.13)
93 21 - 12f3 (0.12)
64 1e - bb8 (0.11)
94 16 - cb8 (0.08)
38 13 - 428 (0.07)
b4 11 - bf4 (0.06)
3e 11 - 41e (0.06)


END OF DIGEST


You are currently subscribed to windbg as: xxxxx@gmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com