memory leak

Discussion:

memory leak

(too old to reply)

RedLars

2008-06-26 15:54:04 UTC

Currently debugging an unmanaged memory leak.

Using this article as a guideline http://www.microsoft.com/whdc/archive/XP_kernel.mspx
(see Built-in User Heap Leak Detection)

0:000> !heap -l
Searching the memory for potential unreachable busy blocks.
Heap 00150000
... 36 other blocks (removed for brevity)
Scanning VM ...
Scanning references from 170901 busy blocks (16
MBytes) ...................
Entry User Heap Segment Size PrevSize Unused
Flags
-----------------------------------------------------------------------------
0018c540 0018c548 00150000 00150000 28 20 8
busy
0018cf30 0018cf38 00150000 00150000 28 50 8
busy
...1030 other blocks (removed for brevity)

The next bit I'm rather uncertain about:

0:000> dc 0018c540+28-8 l1
0018c560 006e0000 ..n.

0:000> dds 006e0000
006e0000 00905a4d og901as!Ordinal24164+0x8761
006e0004 00000003
006e0008 00000004
006e000c 0000ffff
006e0010 000000b8
006e0014 00000000
006e0018 00000040
006e001c 00000000
006e0020 00000000
006e0024 00000000
006e0028 00000000
006e002c 00000000
006e0030 00000000
006e0034 00000000
006e0038 00000000
006e003c 00000100
006e0040 0eba1f0e
006e0044 cd09b400
006e0048 4c01b821
006e004c 685421cd
006e0050 70207369
006e0054 72676f72
006e0058 63206d61
006e005c 6f6e6e61
006e0060 65622074
006e0064 6e757220
006e0068 206e6920
006e006c 20534f44
006e0070 65646f6d
006e0074 0a0d0d2e
006e0078 00000024
006e007c 00000000

#1 What can I actually learn from this output?

#2 Could someone please explain what the command dc and dds are
doing ? Especically confussed about the calculation of the address in
the dc command.

#3 Any other commands I should rather be executing?

Cheers

Ivan Brugiolo [MSFT]

2008-06-26 19:14:40 UTC

Permalink

Instead of trying to reverse-enginner the the heap metadata,
assuming you have at least `gflags.exe -ust` enabled for that process,
you should be able to do `!heap -p -a 0018c540` to get all
the possible information about that heap block.
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Post by RedLars
Currently debugging an unmanaged memory leak.
Using this article as a guideline
http://www.microsoft.com/whdc/archive/XP_kernel.mspx
(see Built-in User Heap Leak Detection)
0:000> !heap -l
Searching the memory for potential unreachable busy blocks.
Heap 00150000
... 36 other blocks (removed for brevity)
Scanning VM ...
Scanning references from 170901 busy blocks (16
MBytes) ...................
Entry User Heap Segment Size PrevSize Unused
Flags
-----------------------------------------------------------------------------
0018c540 0018c548 00150000 00150000 28 20 8
busy
0018cf30 0018cf38 00150000 00150000 28 50 8
busy
...1030 other blocks (removed for brevity)
0:000> dc 0018c540+28-8 l1
0018c560 006e0000 ..n.
0:000> dds 006e0000
006e0000 00905a4d og901as!Ordinal24164+0x8761
006e0004 00000003
006e0008 00000004
006e000c 0000ffff
006e0010 000000b8
006e0014 00000000
006e0018 00000040
006e001c 00000000
006e0020 00000000
006e0024 00000000
006e0028 00000000
006e002c 00000000
006e0030 00000000
006e0034 00000000
006e0038 00000000
006e003c 00000100
006e0040 0eba1f0e
006e0044 cd09b400
006e0048 4c01b821
006e004c 685421cd
006e0050 70207369
006e0054 72676f72
006e0058 63206d61
006e005c 6f6e6e61
006e0060 65622074
006e0064 6e757220
006e0068 206e6920
006e006c 20534f44
006e0070 65646f6d
006e0074 0a0d0d2e
006e0078 00000024
006e007c 00000000
#1 What can I actually learn from this output?
#2 Could someone please explain what the command dc and dds are
doing ? Especically confussed about the calculation of the address in
the dc command.
#3 Any other commands I should rather be executing?
Cheers

RedLars

2008-06-27 06:22:31 UTC

Permalink

Tried your suggestion.

0:000> !heap -p -a 0018c540
address 0018c540 found in
_HEAP @ 150000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0018c540 0005 0000 [01] 0018c548 00020 - (busy)

Since the list contained more than 1000 entries I tried a few random
entries from the list
0:000> !heap -p -a 06514b78
address 06514b78 found in
_HEAP @ 13c0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
06514b78 0003 0000 [01] 06514b80 00010 - (busy)
OSKFunctionManager!CBatchFunctionItem::`vftable'

0:000> !heap -p -a 0177f9d0
address 0177f9d0 found in
_HEAP @ 13c0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0177f9d0 0006 0000 [01] 0177f9d8 00028 - (busy)
PCKIBASIS!CPckModAlg::`vftable'

0:000> !heap -p -a 0845ccd0
address 0845ccd0 found in
_HEAP @ 13c0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0845ccd0 0004 0000 [01] 0845ccd8 00013 - (busy)
? mfc70!Ordinal3939+29d8

A lot of execution did not refer to any stacktrace but those that did,
mostly referred to a single line with a 'vftable'.

#1 Does the fact that a reference to OSKFunctionManager!
CBatchFunctionItem indicate such an object was created but not
deleted?

#2 Any particular reason why I'm seeing a lof of references to
'vftable' ?

#3 How can I find out whom has a reference to any of these addresses?
(i

Thanks for your help Ivan B.

On 26 Jun, 21:14, "Ivan Brugiolo [MSFT]"

Post by Ivan Brugiolo [MSFT]
Instead of trying to reverse-enginner the the heap metadata,
assuming you have at least `gflags.exe -ust` enabled for that process,
you should be able to do `!heap -p -a 0018c540` to get all
the possible information about that heap block.
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified athttp://www.microsoft.com/info/cpyright.htm

Ivan Brugiolo [MSFT]

2008-06-27 09:18:27 UTC

Permalink

First of all, the fact that you do not get stack traces
when you do `!heap -p -a <address>` suggests me that
you either did not enable user-mode-stack-traces, or, the
stack-backtrace database is too small, or something else is wrong
in the configuration or the environment.

Post by RedLars
#1 Does the fact that a reference to OSKFunctionManager!
CBatchFunctionItem indicate such an object was created but not
deleted?

Normally the status of the block is listed as (busy) or (free)
depending if the block has not been deleted or it has been.

Post by RedLars
#2 Any particular reason why I'm seeing a lof of references to
'vftable' ?

Not any particular reason. The debugger extension is designed to
try to understand the first ULONG_PTR as a symbol, and, if there is
a match, the mathcing symbols is printed.
On the most common cases, if the block is a C++ object, then,
the fist ULONG_PTR is a vtable, and, you can easily identify the block.

Post by RedLars
#3 How can I find out whom has a reference to any of these addresses?

There is no silver-bullet mechanism, but, you can try the following steps:
0:000> s -d 1000 L?40000000 <address>
That command will print a bunch of lines like
[referencing address] [<address>] [un-interesting-1] [un-interesting-2]
[un-interesting-3]
for each [referencing address] you can do `!address <referencing-address>`
andm you can find is heap, stack of a thread, or something else references
that address.
If is is heap, you can do `!heap -p -a <referencing-address>` and find out
more.
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Post by RedLars
Tried your suggestion.
0:000> !heap -p -a 0018c540
address 0018c540 found in
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0018c540 0005 0000 [01] 0018c548 00020 - (busy)
Since the list contained more than 1000 entries I tried a few random
entries from the list
0:000> !heap -p -a 06514b78
address 06514b78 found in
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
06514b78 0003 0000 [01] 06514b80 00010 - (busy)
OSKFunctionManager!CBatchFunctionItem::`vftable'
0:000> !heap -p -a 0177f9d0
address 0177f9d0 found in
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0177f9d0 0006 0000 [01] 0177f9d8 00028 - (busy)
PCKIBASIS!CPckModAlg::`vftable'
0:000> !heap -p -a 0845ccd0
address 0845ccd0 found in
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0845ccd0 0004 0000 [01] 0845ccd8 00013 - (busy)
? mfc70!Ordinal3939+29d8
A lot of execution did not refer to any stacktrace but those that did,
mostly referred to a single line with a 'vftable'.
#1 Does the fact that a reference to OSKFunctionManager!
CBatchFunctionItem indicate such an object was created but not
deleted?
#2 Any particular reason why I'm seeing a lof of references to
'vftable' ?
#3 How can I find out whom has a reference to any of these addresses?
(i
Thanks for your help Ivan B.
On 26 Jun, 21:14, "Ivan Brugiolo [MSFT]"