青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

Ay's Blog@CNSSUESTC

WINDBG的堆調(diào)試--了解HEAP組織

@作者: ay @文章出處: cnss-ay的博客@Notice: 轉(zhuǎn)載請注明出處!若文章顯示不完整,可以到文章出處閱讀。

HEAP的概念

堆棧堆棧,在操作系統(tǒng)內(nèi)存中有兩種存儲空間,一個是堆,一個是棧。堆主要用于存儲用戶動態(tài)分配的變量,而棧呢,則是存儲我們程序過程中的臨時變量。當(dāng)然棧的作用遠(yuǎn)不止用作存儲變量,但這不是我們這篇文章的討論內(nèi)容。

?

堆(HEAP)的分配,使用,回收都是通過微軟的API來管理的,最常見的API是malloc和new。在往底層走一點呢,這兩個函數(shù)都會調(diào)用HeapAlloc(RtlAllocateHeap)。同樣的相關(guān)函數(shù)還有HeapFree用來釋放堆,HeapCreate用來創(chuàng)建自己的私有堆。下面是這些函數(shù)的調(diào)用鏈:

HeapCreate->RtlCreateHeap->ZwAllocateVirtualMemory? (這里會直接申請一大片內(nèi)存,至于申請多大內(nèi)存,由進(jìn)程PEB結(jié)構(gòu)中的字段覺得,HeapSegmentReserve字段指出要申請多大的虛擬內(nèi)存,HeapSegmentCommit指明要提交多大內(nèi)存,對虛擬內(nèi)存的申請和提交概念不清楚的童鞋,請參見windows核心編程相關(guān)內(nèi)容~)

HeapAlloc->RtlAllocateHeap(至于這里申請的內(nèi)存,由于HeapCreate已經(jīng)申請了一大片內(nèi)存,堆管理器這片內(nèi)存中劃分一塊出來以滿足申請的需要。這一步申請操作是堆管理器自己維護(hù)的,僅當(dāng)申請內(nèi)存不夠的時候才會再次調(diào)用ZwAllocateVirtualMemory

HeapFree->RtlFreeHeap (對于釋放的內(nèi)存,堆管理器只是簡單的把這塊內(nèi)存標(biāo)志位已釋放讓后加入到空閑列表中,僅當(dāng)空閑的內(nèi)存達(dá)到一定閥值的時候會調(diào)用ZwFreeVirtualMeMory

HeapDestroy->RtlDestroyHeap->ZwFreeVirtualMeMory?? (銷毀我們申請的堆)

如何找到我們的HEAP信息?

WINDBG觀察堆

源碼:

#include "windows.h"

int main()
{
	HANDLE heap_handle = HeapCreate( NULL , 0x1000 , 0x2000 ) ;

	char *buffer = (char*)HeapAlloc(heap_handle , NULL , 128) ;

	char *buffer1 = (char*)HeapAlloc(heap_handle , NULL , 121) ;

	HeapFree(heap_handle, 0 , buffer ) ;
	HeapFree(heap_handle, 0 , buffer1 ) ;

	HeapDestroy( heap_handle) ;
	return 0 ;
}

該源碼生成編譯生成heap.exe,然后用windbg調(diào)試這個程序,在main函數(shù)下斷,緊接著執(zhí)行第五行語句,執(zhí)行結(jié)果如下

0:000> p
eax=002e1ca0 ebx=00000000 ecx=6d29b6f0 edx=00000000 esi=00000001 edi=01033374
eip=01031012 esp=0022fe8c ebp=0022feac iopl=0???????? nv up ei pl nz na po nc
cs=001b? ss=0023? ds=0023? es=0023? fs=003b? gs=0000???????????? efl=00000202
heap!main+0x12:
01031012 ff150c200301??? call??? dword ptr [heap!_imp__HeapCreate (0103200c)] ds:0023:0103200c={kernel32!HeapCreateStub (769a29d7)}

0:000> p
eax=002c0000 ebx=00000000 ecx=77429897 edx=77498500 esi=00000001 edi=01033374
eip=01031018 esp=0022fe98 ebp=0022feac iopl=0???????? nv up ei pl nz na pe nc
cs=001b? ss=0023? ds=0023? es=0023? fs=003b? gs=0000???????????? efl=00000206
heap!main+0x18:
01031018 8945fc????????? mov???? dword ptr [ebp-4],eax ss:0023:0022fea8=6d222201
0:000> !heap
Index?? Address? Name????? Debugging options enabled
? 1:?? 00300000???????????????
? 2:?? 00010000???????????????
? 3:?? 00020000???????????????
? 4:?? 002e0000???????????????
? 5:?? 002c0000??????

HeapCreate執(zhí)行的返回值存放在eax處,這個函數(shù)返回了一個堆句柄:0x002c0000。用!heap命令查看可以看到第五個堆就是我們創(chuàng)建的堆句柄了。

每個進(jìn)程都存在多個堆,我們也可以通過PEB結(jié)構(gòu)來得到進(jìn)程中存在的堆,結(jié)果和!heap命令顯示的內(nèi)容是一樣的。

heap!_PEB
?? +0x018 ProcessHeap????? : 0x00300000 Void???????? ; 進(jìn)程的默認(rèn)堆
?? +0x068 NtGlobalFlag???? : 0?????????????????????????????????????? ; 這個標(biāo)志位記錄了當(dāng)前堆調(diào)試模式,0為普通調(diào)試模式
?? +0x078 HeapSegmentReserve : 0x100000????????? ; 進(jìn)程在新建堆的時候默認(rèn)申請的虛擬內(nèi)存大小
?? +0x07c HeapSegmentCommit : 0x2000?????????????? ; 進(jìn)程在每次申請?zhí)峤坏奶摂M內(nèi)存大小,在提交的內(nèi)存用完后,進(jìn)程會又在一次提交HeapSegmentCommit中指定的內(nèi)存大小
?? +0x080 HeapDeCommitTotalFreeThreshold : 0x10000??? ; 當(dāng)釋放的內(nèi)存大小大于這個閥值,就進(jìn)行內(nèi)存解除提交操作
?? +0x084 HeapDeCommitFreeBlockThreshold : 0x1000???? ;? 當(dāng)一次性釋放的塊大小超過這個閥值,就進(jìn)行內(nèi)存解除提交操作,只有當(dāng)滿足這兩個條件時才會調(diào)用ZwFreeVirtualMeMory 釋放物理內(nèi)存
?? +0x088 NumberOfHeaps??? : 5?????????????????????????????????????????????? ; 當(dāng)前進(jìn)程的堆數(shù)目,這個數(shù)目對應(yīng)著!heap命令的堆顯示個數(shù)
?? +0x08c MaximumNumberOfHeaps : 0x10????????????????????????? ; 進(jìn)程所能運行的最大堆數(shù)目,若堆數(shù)目超過這個值估計HeapCreate就失敗了吧
?? +0x090 ProcessHeaps???? : 0x77498500? -> 0x00300000 Void ;存儲堆句柄的數(shù)組,這里我們可以得到進(jìn)程的所有堆句柄

我們可以輸入如下命令來查看現(xiàn)有的堆句柄

0:000> dd 0x77498500?
77498500? 00300000 00010000 00020000 002e0000
77498510? 002c0000 00000000 00000000 00000000
77498520? 00000000 00000000 00000000 00000000
77498530? 00000000 00000000 00000000 00000000
77498540? 00000000 77498340 7749bb08 77498220
77498550? 00000000 00000000 00000000 00000000
77498560? 77498220 00317bd0 00000000 00000000
77498570? 00000000 00000000 00000000 00000000

可以看得到這里面的內(nèi)容和!heap命令的輸出結(jié)果是一樣的

而堆句柄的存放范圍,從MaximumNumberOfHeaps 上來看,就是77498500-77498540這0x40個字節(jié),因為每個堆句柄占4個字節(jié),0x10個堆句柄的存放空間就是0x40。

HEAP的組織結(jié)構(gòu)

堆的管理,我們可以理解為一個內(nèi)存池,它申請一大塊空間,然后負(fù)責(zé)接管應(yīng)用程序的申請釋放等請求。只有在創(chuàng)建堆,釋放堆(注意!是釋放堆,不是堆中的空間!)在這之前,我們需要對堆有關(guān)的數(shù)據(jù)結(jié)構(gòu)做一些解釋

我這里觀察到的HEAP結(jié)構(gòu),HEAP_SEGMENT結(jié)構(gòu)和HEAP_ENTRY結(jié)構(gòu)都和軟件調(diào)試?yán)锩婷枋龅牟灰粯樱?dāng)年奎哥寫軟件調(diào)試的時候估計還沒用上WIN7吧。。。我的演示系統(tǒng)是WIN7

HeapCreate函數(shù)返回的堆句柄其實就是一個指向堆管理結(jié)構(gòu)的指針,每個堆都會涉及到這樣三個結(jié)構(gòu):HEAP,HEAP_SEGMENT,HEAP_ENTRY

HEAP_ENTRY結(jié)構(gòu):

在堆管理中,每一塊申請下來的內(nèi)存都會有下面所示的固定模式:

HEAP_ENTRY(8 bytes)

我們new或malloc分配的空間

固定填充空間

這個結(jié)構(gòu)用來記錄所分配的空間的信息,包括用戶申請的空間,填充的空間,所在的段號等等信息。所以我們new或者malloc的地址減去8就指向該結(jié)構(gòu)。第三部分的固定填充空間是為了內(nèi)存對齊而生成的,當(dāng)然這部分空間還有一部分是用來額外記錄這塊內(nèi)存的其它信息,這里就不詳細(xì)做介紹了。

HEAP_SEGMENT結(jié)構(gòu):

我們可以這么認(rèn)為,堆申請內(nèi)存的大小是以段為單位的,當(dāng)新建一個堆的時候,系統(tǒng)會默認(rèn)為這個堆分配一個段叫0號段,通過剛開始的new和malloc分配的空間都是在這個段上分配的,當(dāng)這個段用完的時候,如果當(dāng)初創(chuàng)建堆的時候指明了HEAP_GROWABLE這個標(biāo)志,那么系統(tǒng)會為這個堆在再分配一個段,這個時候新分配的段就稱為1號段了,以下以此類推。每個段的開始初便是HEAP_SEGMENT結(jié)構(gòu)的首地址,由于這個結(jié)構(gòu)也是申請的一塊內(nèi)存,所以它前面也會有個HEAP_ENTRY結(jié)構(gòu):

HEAP_ENTRY(8 bytes)

HEAP_SEGMENT

HEAP_ENTRY(8 bytes)

我們new或malloc分配的空間

固定填充空間

HEAP_SEGMENT結(jié)構(gòu)會記錄段的一些基本信息,該段申請的大小,已經(jīng)提交內(nèi)存的大小,第一個HEAP_ENTRY結(jié)構(gòu)的入口點。(我觀察看貌似段申請的內(nèi)存并不會一次性全部提交,而是每次提交一個頁的大小,比如一個段大小2個頁,那么它會先提交一個頁內(nèi)存,若用完了再提交一個頁的內(nèi)存,若內(nèi)存還用完了那就新建一個段,這個新建的段也會是先提交一個頁內(nèi)存。)但是0號段很特別,這個段的起始地址就是堆句柄指針指向的值,也就是說,HeapCreate返回的堆句柄總是指向0號段,為什么呢?因為HEAP結(jié)構(gòu)是HEAP_ENTRY,HEAP_SEGMENT的合體加長版~

HEAP結(jié)構(gòu):

HEAP結(jié)構(gòu)則是記錄了這個堆的信息,這個結(jié)構(gòu)可以找到HEAP_SEGMENT鏈表入口,空閑內(nèi)存鏈表的入口,內(nèi)存分配粒度等等信息。HEAP的首地址便是堆句柄的值,但是堆句柄的值又是0號段的首地址也是堆句柄,何解?其實很簡單,0號段的HEAP_SEGMENT就在HEAP結(jié)構(gòu)里面,HEAP結(jié)構(gòu)類定義如這樣:

struct _HEAP

{

_HEAP_ENTRY Entry ; //HEAP_ENTRY結(jié)構(gòu),用來描述存儲HEAP內(nèi)存塊大小等信息的

_HEAP_SEGMENT Segment ;  //0號段的首地址

……  //對于該HEAP的描述信息

} ;

在我們看來,內(nèi)存組織結(jié)構(gòu)應(yīng)該如下所示:

HEAP_ENTRY(8 bytes)

HEAP_SEGMENT

HEAP

更確切的說,HEAP結(jié)構(gòu)中本身就包含了HEAP_ENTRY和HEAP_SEGMENT,HEAP_ENTRY結(jié)構(gòu)是HEAP的第一個數(shù)據(jù)成員,HEAP_SEGMENT是它第二個數(shù)據(jù)成員。而對于HEAP_SEGMENT,它的第一個數(shù)據(jù)成員便是HEAP_ENTRY。這里為了方便理解,才在內(nèi)存組織結(jié)構(gòu)中把它們拆開展示。(注:這里是win7的情況,和軟件調(diào)試這本書中所描述的有一些差異,也屬正常現(xiàn)象,畢竟這部分結(jié)構(gòu)微軟并未公開)

用WINDBG觀察HEAP結(jié)構(gòu)

在之前已經(jīng)演示了如何從PEB結(jié)構(gòu)中找到所有的堆句柄,可以看到002c0000便是我們創(chuàng)建的句柄。然后我們執(zhí)示例程序的第7行代碼。執(zhí)行完后結(jié)果如下:

0:000> p
eax=002c0000 ebx=00000000 ecx=77429897 edx=77498500 esi=00000001 edi=01033374
eip=01031026 esp=0022fe8c ebp=0022feac iopl=0???????? nv up ei pl nz na pe nc
cs=001b? ss=0023? ds=0023? es=0023? fs=003b? gs=0000???????????? efl=00000206
heap!main+0x26:
01031026 ff1500200301??? call??? dword ptr [heap!_imp__HeapAlloc (01032000)] ds:0023:01032000={ntdll!RtlAllocateHeap (774120b5)}
0:000> p
eax=002c0590 ebx=00000000 ecx=774134b4 edx=002c0180 esi=00000001 edi=01033374
eip=0103102c esp=0022fe98 ebp=0022feac iopl=0???????? nv up ei pl zr na pe nc
cs=001b? ss=0023? ds=0023? es=0023? fs=003b? gs=0000???????????? efl=00000246
heap!main+0x2c:
0103102c 8945f0????????? mov???? dword ptr [ebp-10h],eax ss:0023:0022fe9c={heap!envp (0103301c)}

可以看到EAX保存的返回值為002c0590。我們通過兩種途徑來觀察我們申請的內(nèi)存,通過!heap命令觀察和通過dt命令觀察

通過!heap命令觀察

輸入命令!heap –a 2c0590得到的結(jié)果如下:

0:000> !heap -a 2c0000
Index?? Address? Name????? Debugging options enabled
? 5:?? 002c0000
??? Segment at 002c0000 to 002c2000 (00001000 bytes committed)
??? Flags:??????????????? 00001000
??? ForceFlags:?????????? 00000000
??? Granularity:????????? 8 bytes
??? Segment Reserve:????? 00100000
??? Segment Commit:?????? 00002000
??? DeCommit Block Thres: 00000200
??? DeCommit Total Thres: 00002000
??? Total Free Size:????? 0000013a
??? Max. Allocation Size: 7ffdefff
??? Lock Variable at:???? 002c0138
??? Next TagIndex:??????? 0000
??? Maximum TagIndex:???? 0000
??? Tag Entries:????????? 00000000
??? PsuedoTag Entries:??? 00000000
??? Virtual Alloc List:?? 002c00a0
??? Uncommitted ranges:?? 002c0090
??????????? 002c1000: 00001000? (4096 bytes)
??? FreeList[ 00 ] at 002c00c4: 002c0618 . 002c0618?
??????? 002c0610: 00088 . 009d0 [100] - free

??? Segment00 at 002c0000:
??????? Flags:?????????? 00000000
??????? Base:??????????? 002c0000
??????? First Entry:???? 002c0588
??????? Last Entry:????? 002c2000
??????? Total Pages:???? 00000002
??????? Total UnCommit:? 00000001
??????? Largest UnCommit:00000000
??????? UnCommitted Ranges: (1)

??? Heap entries for Segment00 in Heap 002c0000
??????? 002c0000: 00000 . 00588 [101] - busy (587)
??????? 002c0588: 00588 . 00088 [101] - busy (80)
??????? 002c0610: 00088 . 009d0 [100]
??????? 002c0fe0: 009d0 . 00020 [111] - busy (1d)
??????? 002c1000:????? 00001000????? - uncommitted bytes.

這個命令分別提煉出了HEAP(綠色區(qū)域),HEAP_SEGMENT(紅色區(qū)域)和HEAP_ENTRY(灰色區(qū)域)結(jié)構(gòu)中的信息。雖然在灰色區(qū)域中,我們找不到2c0590,但是找到了一個2c0588,這個正是2c0590-8的結(jié)果,也就是說最右邊的地址是每個HEAP_ENTRY的首地址,接著00588這個字段表示了前面一個HEAP_ENTRY所占用的大小,后面的0088表示這個內(nèi)存塊的總大小,即我們申請的內(nèi)存+HEAP_ENTRY(128+8=0x80+0x8=0x88),[101]是這塊內(nèi)存的標(biāo)志位,最右邊一位為1表示該內(nèi)存塊被占用。然后busy(80)就是解釋說這塊內(nèi)存是被占用的(非空閑的),它申請的內(nèi)存為0x80,轉(zhuǎn)化成十進(jìn)制正好就是我們申請的128字節(jié)大小。

但是這里用dt _HEAP_ENTRY 2c0588命令卻沒辦法查看對應(yīng)的結(jié)構(gòu)信息,真是怪哉,有篇博文也提到win2008中HEAP相關(guān)結(jié)構(gòu)也有變,看來到NT6后,HEAP結(jié)構(gòu)變得不小,起碼windbg中直接dt HEAP_ENTRY是無法原始數(shù)據(jù)的了,貌似對HEAP_ENTRY做了編碼。

通過dt命令觀察

同樣的,已知HEAP的首地址,那么先從HEAP下手好了,dt _HEAP 002c0000可以顯示HEAP的數(shù)據(jù)結(jié)構(gòu)

ntdll!_HEAP
?? +0x000 Entry??????????? : _HEAP_ENTRY
?? +0x008 SegmentSignature : 0xffeeffee??
?? +0x00c SegmentFlags???? : 0
?? +0x010 SegmentListEntry : _LIST_ENTRY [ 0x2c00a8 - 0x2c00a8 ]
?? +0x018 Heap???????????? : 0x002c0000 _HEAP
?? +0x01c BaseAddress????? : 0x002c0000 Void
?? +0x020 NumberOfPages??? : 2
?? +0x024 FirstEntry?????? : 0x002c0588 _HEAP_ENTRY
?? +0x028 LastValidEntry?? : 0x002c2000 _HEAP_ENTRY
?? +0x02c NumberOfUnCommittedPages : 1
?? +0x030 NumberOfUnCommittedRanges : 1
?? +0x034 SegmentAllocatorBackTraceIndex : 0
?? +0x036 Reserved???????? : 0
?? +0x038 UCRSegmentList?? : _LIST_ENTRY [ 0x2c0ff0 - 0x2c0ff0 ]

?? +0x040 Flags??????????? : 0x1000
?? +0x044 ForceFlags?????? : 0
?? +0x048 CompatibilityFlags : 0
?? +0x04c EncodeFlagMask?? : 0x100000
?? +0x050 Encoding???????? : _HEAP_ENTRY
?? +0x058 PointerKey?????? : 0x17c06e63
?? +0x05c Interceptor????? : 0
?? +0x060 VirtualMemoryThreshold : 0xfe00
?? +0x064 Signature??????? : 0xeeffeeff
?? +0x068 SegmentReserve?? : 0x100000
?? +0x06c SegmentCommit??? : 0x2000
?? +0x070 DeCommitFreeBlockThreshold : 0x200
?? +0x074 DeCommitTotalFreeThreshold : 0x2000
?? +0x078 TotalFreeSize??? : 0x13a
?? +0x07c MaximumAllocationSize : 0x7ffdefff
?? +0x080 ProcessHeapsListIndex : 5
?? +0x082 HeaderValidateLength : 0x138
?? +0x084 HeaderValidateCopy : (null)
?? +0x088 NextAvailableTagIndex : 0
?? +0x08a MaximumTagIndex? : 0
?? +0x08c TagEntries?????? : (null)
?? +0x090 UCRList????????? : _LIST_ENTRY [ 0x2c0fe8 - 0x2c0fe8 ]
?? +0x098 AlignRound?????? : 0xf
?? +0x09c AlignMask??????? : 0xfffffff8
?? +0x0a0 VirtualAllocdBlocks : _LIST_ENTRY [ 0x2c00a0 - 0x2c00a0 ]
?? +0x0a8 SegmentList????? : _LIST_ENTRY [ 0x2c0010 - 0x2c0010 ]
?? +0x0b0 AllocatorBackTraceIndex : 0
?? +0x0b4 NonDedicatedListLength : 0
?? +0x0b8 BlocksIndex????? : 0x002c0150 Void
?? +0x0bc UCRIndex???????? : (null)
?? +0x0c0 PseudoTagEntries : (null)
?? +0x0c4 FreeLists??????? : _LIST_ENTRY [ 0x2c0618 - 0x2c0618 ]
?? +0x0cc LockVariable???? : 0x002c0138 _HEAP_LOCK
?? +0x0d0 CommitRoutine??? : 0x17c06e63???? long? +17c06e63
?? +0x0d4 FrontEndHeap???? : (null)
?? +0x0d8 FrontHeapLockCount : 0
?? +0x0da FrontEndHeapType : 0 ''
?? +0x0dc Counters???????? : _HEAP_COUNTERS
?? +0x130 TuningParameters : _HEAP_TUNING_PARAMETERS
就如本文前面所述的,第一個字段是HEAP_ENTRY結(jié)構(gòu),接著應(yīng)該是HEAP_SEGMENT,這里只不過把HEAP_SEGMENT結(jié)構(gòu)的字段展開了,可以dt _HEAP_SEGMENT來觀察下這個結(jié)構(gòu)的字段

0:000> dt _heap_segment
ntdll!_HEAP_SEGMENT
?? +0x000 Entry??????????? : _HEAP_ENTRY
?? +0x008 SegmentSignature : Uint4B
?? +0x00c SegmentFlags???? : Uint4B
?? +0x010 SegmentListEntry : _LIST_ENTRY
?? +0x018 Heap???????????? : Ptr32 _HEAP
?? +0x01c BaseAddress????? : Ptr32 Void
?? +0x020 NumberOfPages??? : Uint4B
?? +0x024 FirstEntry?????? : Ptr32 _HEAP_ENTRY
?? +0x028 LastValidEntry?? : Ptr32 _HEAP_ENTRY
?? +0x02c NumberOfUnCommittedPages : Uint4B
?? +0x030 NumberOfUnCommittedRanges : Uint4B
?? +0x034 SegmentAllocatorBackTraceIndex : Uint2B
?? +0x036 Reserved???????? : Uint2B
?? +0x038 UCRSegmentList?? : _LIST_ENTRY

可以看到HEAP結(jié)構(gòu)中灰色部分是和HEAP_SEGMENT結(jié)構(gòu)中的字段是重復(fù)的,也就是說灰色部分字段便是HEAP_SEGMENT結(jié)構(gòu)。在HEAP_SEGMENT結(jié)構(gòu)中,我們可以找到FirstEntry字段,這里指的便是我們的分配的內(nèi)存,不過HEAP_ENTRY結(jié)構(gòu)無法觀察,這里便沒辦法枚舉出所有的HEAP_ENTRY結(jié)構(gòu)了,但是說一下思路:

每個HEAP_ENTRY和它對應(yīng)的內(nèi)存我們可以稱為一個內(nèi)存塊,計算下一個內(nèi)存塊需要用到現(xiàn)有內(nèi)存塊中的2個字段,Size和UnsedBytes,Size的值乘上粒度(就是0:000> !heap -a 2c0000命令顯示的信息中的Granularity: 8 bytes字段,這里是8字節(jié)),下一個內(nèi)存塊地址就是 本內(nèi)存塊地址+Size*8+UnsedBytes。當(dāng)然這里的粒度可以通過HEAP字段中的AlignMask 字段算出來。

HEAP的分配粒度

在HEAP結(jié)構(gòu)中指明了分配粒度,這個分配粒度是說每次堆分配的時候,都以這個粒度為最小單位,這里看到粒度為8字節(jié)。所以這里就有了第二次分配內(nèi)存的實驗,我們讓程序執(zhí)行第9行,然后用!heap -a 002c0000觀察分配情況

Heap entries for Segment00 in Heap 002c0000
??? 002c0000: 00000 . 00588 [101] - busy (587)
??? 002c0588: 00588 . 00088 [101] - busy (80)
??? 002c0610: 00088 . 00088 [101] - busy (79)
??? 002c0698: 00088 . 00948 [100]
??? 002c0fe0: 00948 . 00020 [111] - busy (1d)
??? 002c1000:????? 00001000????? - uncommitted bytes.

這里可以看出多出了一個占用塊,大小是0x79(121) bytes,但是實際分配的大小還是0x 88 (128)bytes,這是因為系統(tǒng)是以8 bytes為粒度分配的,所以為這塊121 bytes的內(nèi)存自動填充了7個字節(jié),可見申請121 bytes和申請128 bytes所使用的空間是一樣的。

HEAP的釋放和銷毀

執(zhí)行了11行和12行的代碼后,堆中的內(nèi)容分別如下:

執(zhí)行11行代碼的堆情況

FreeList[ 00 ] at 002c00c4: 002c06a0 . 002c0590?
??? 002c0588: 00588 . 00088 [100] – free?? ;空閑列表中多出了一塊內(nèi)存
??? 002c0698: 00088 . 00948 [100] – free?? ;空閑內(nèi)存,空閑空間為948

Heap entries for Segment00 in Heap 002c0000
002c0000: 00000 . 00588 [101] - busy (587)
002c0588: 00588 . 00088 [100]?? ;原先的這塊內(nèi)存釋放掉了
002c0610: 00088 . 00088 [101] - busy (79)
002c0698: 00088 . 00948 [100]??? ; 空閑內(nèi)存
002c0fe0: 00948 . 00020 [111] - busy (1d)
002c1000: 00001000 - uncommitted bytes.

執(zhí)行12行代碼的堆情況

FreeList[ 00 ] at 005c00c4: 005c0590 . 005c0590?
??? 005c0588: 00588 . 00a58 [100] – free ;回收了buffer1的內(nèi)存后,由于由于空閑內(nèi)存是連續(xù)的,所以直接合并成一塊內(nèi)存。可以看到之前內(nèi)存free空間是948,現(xiàn)在合并了以后便是948+88+88=a58,也就是當(dāng)前內(nèi)存大小

Heap entries for Segment00 in Heap 005c0000
??? 005c0000: 00000 . 00588 [101] - busy (587)
??? 005c0588: 00588 . 00a58 [100]
??? 005c0fe0: 00a58 . 00020 [111] - busy (1d)
??? 005c1000:????? 00001000????? - uncommitted bytes.

最后執(zhí)行14行代碼,對堆進(jìn)行釋放,釋放后我們通過!heap也可以看到只有4個堆了,我們申請的堆被釋放了.

0:000> !heap
Index Address Name Debugging options enabled
1: 00300000
2: 00010000
3: 00020000
4: 002e0000

?

至于HEAP_ENTRY結(jié)構(gòu)的問題,有時間在調(diào)試看看是怎么回事吧~另外,這里說明下,new和malloc內(nèi)部都會調(diào)用HeapAlloc來申請內(nèi)存,但是堆句柄從哪來呢?它會檢測_crtheap變量是否為空,若不為空則拿_crtheap變量來作為自己的堆句柄去調(diào)用HeapAlloc

參考:

軟件調(diào)試??? 張奎銀

MSDN???

React OS

posted on 2011-10-30 19:05 __ay 閱讀(11102) 評論(0)  編輯 收藏 引用 所屬分類: Debugging

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            国产精品区一区二区三| 久久精品免视看| 国产伦理一区| 国产精品人人爽人人做我的可爱| 欧美日韩国产色综合一二三四 | 欧美精品情趣视频| 欧美三级网址| 国产欧美一区二区精品忘忧草 | 欧美在线免费| 久久午夜国产精品| 男女激情久久| 亚洲激情在线观看| 亚洲精品乱码久久久久久蜜桃麻豆 | 欧美激情中文字幕乱码免费| 亚洲激情一区| 亚洲欧美日本伦理| 久久人人爽人人| 欧美日韩精品一区二区天天拍小说 | 欧美日韩综合在线| 国产日韩欧美二区| 亚洲激情第一区| 午夜久久久久久| 欧美风情在线观看| 亚洲女同性videos| 牛人盗摄一区二区三区视频| 国产精品捆绑调教| 亚洲国产另类久久精品| 欧美一级成年大片在线观看| 欧美黑人在线观看| 欧美一区二区三区视频免费| 欧美日韩国产黄| 亚洲高清不卡一区| 亚洲美女诱惑| 午夜一区二区三视频在线观看 | 国产手机视频精品| 亚洲精品三级| 一区二区免费看| 亚洲欧美日本伦理| 欧美成人在线影院| 国产日本欧美一区二区| 亚洲欧洲美洲综合色网| 欧美一区2区视频在线观看| 欧美成人精品福利| 性欧美大战久久久久久久免费观看| 欧美96在线丨欧| 韩日欧美一区| 久久成人av少妇免费| 亚洲美女电影在线| 欧美成人免费在线| 亚洲高清不卡在线| 模特精品在线| 久久久精品2019中文字幕神马| 国产精品色在线| 亚洲女优在线| 一区二区日韩伦理片| 欧美精品一区二| 亚洲精品女av网站| 亚洲国产精品久久久久| 浪潮色综合久久天堂| 尤妮丝一区二区裸体视频| 久久久久国产精品午夜一区| 午夜精彩视频在线观看不卡| 国产精品尤物| 久久国产一区二区三区| 欧美亚洲综合在线| 精品成人一区二区三区| 久久综合伊人77777尤物| 久久精品免视看| 亚洲福利视频网站| 亚洲国产精品久久久久秋霞蜜臀| 欧美v亚洲v综合ⅴ国产v| 亚洲精品久久久久久久久久久| 亚洲电影自拍| 欧美日韩黄色一区二区| 亚洲免费在线观看视频| 亚洲一区二区少妇| 国产亚洲在线| 欧美成人免费一级人片100| 麻豆9191精品国产| 一区二区av| 亚洲欧美视频一区二区三区| 国产一二三精品| 亚洲国产精品第一区二区| 欧美日韩亚洲一区二区三区在线 | 国产精品红桃| 欧美有码在线观看视频| 久久精品日韩| 亚洲精美视频| 一区二区日韩精品| 国内精品久久久久久影视8 | 欧美一区二区免费观在线| 国内外成人免费激情在线视频网站| 久久婷婷色综合| 欧美日韩国产三级| 久久久久www| 欧美日韩aaaaa| 欧美专区在线观看| 欧美成人精品| 欧美一区二区三区的| 久久久久久久尹人综合网亚洲| 亚洲乱码国产乱码精品精| 亚洲无线视频| 亚洲国产cao| 亚洲综合国产| 日韩系列欧美系列| 欧美在线免费看| 亚洲天堂免费在线观看视频| 久久国产精品72免费观看| 亚洲精品一区二区三区在线观看 | 亚洲综合第一页| 久久综合网络一区二区| 午夜精品久久久久99热蜜桃导演| 久久综合给合| 久久久精品一区| 国产精品久久久久久五月尺| 欧美激情小视频| 影音先锋亚洲电影| 欧美亚洲在线| 欧美一区二区高清在线观看| 欧美多人爱爱视频网站| 老鸭窝亚洲一区二区三区| 国产伦理一区| 亚洲欧美国产精品桃花| 亚洲一区二区三区激情| 欧美激情第10页| 亚洲电影在线看| 亚洲激情在线视频| 卡一卡二国产精品| 久久尤物视频| 精品999久久久| 久久成人羞羞网站| 久久久久久久国产| 国产亚洲精品v| 欧美一区二区精品在线| 久久丁香综合五月国产三级网站| 国产精品久久毛片a| 亚洲婷婷综合色高清在线| 亚洲深夜福利视频| 国产精品久久久久久久久久妞妞| 亚洲视频在线观看免费| 亚洲免费小视频| 国产免费一区二区三区香蕉精| 亚洲一区免费看| 久久激情网站| 国产一区二区日韩精品| 久久精品30| 欧美高清视频免费观看| 久久精品亚洲| 国产一区二区三区在线观看网站| 午夜亚洲福利在线老司机| 久久国产精品99精品国产| 国产日本欧洲亚洲| 久久久久9999亚洲精品| 欧美激情四色 | 亚洲国产精品传媒在线观看| 日韩一区二区精品| 国产精品精品视频| 久久国产一区| 亚洲国产专区校园欧美| 中文精品在线| 国产视频不卡| 欧美激情在线免费观看| 亚洲午夜免费福利视频| 久久激情五月丁香伊人| 亚洲人成亚洲人成在线观看| 欧美视频一区二| 性欧美video另类hd性玩具| 牛牛影视久久网| 亚洲一区二区三区三| 国精产品99永久一区一区| 欧美成人一区二区三区| 亚洲一区二区三区精品动漫| 欧美mv日韩mv国产网站app| 亚洲视频电影图片偷拍一区| 国产亚洲欧美激情| 欧美日韩国产首页在线观看| 欧美有码视频| 中文一区字幕| 亚洲电影专区| 久久久综合网站| 亚洲一区二区三区免费观看 | 老司机精品视频网站| 夜夜精品视频| 影音先锋久久| 国产日韩欧美在线观看| 欧美精品一区在线发布| 性做久久久久久免费观看欧美| 亚洲三级电影在线观看| 久久综合伊人77777| 午夜在线一区二区| aa亚洲婷婷| 亚洲国产婷婷| 韩国美女久久| 国产欧美一区二区三区沐欲| 欧美日韩精品一二三区| 欧美xart系列高清| 老牛嫩草一区二区三区日本| 欧美一级久久久| 先锋影音国产一区| 亚洲一区二区三区精品视频|