2012-03-08 5 views
0

0xA8バイトを割り当てるように要求されたときにオペレータnewが0x1ff8を返すのはなぜですか?なぜHeapAllocはサイズ0x1ff8のバッファを返しますか? (XP SP3でテスト済み)

一定のオーバーヘッドがそれぞれ要求されたメモリに追加されるよう要求されたサイズが少し大きくなりますけれども、ヒープのメモリプール(複数可)の大きさではなく、あなたのプログラムに行われた、単一の割り当てのサイズ(である
0:016> u IEFRAME!CIntShcut_CreateInstance+0x3 

IEFRAME!CIntShcut_CreateInstance+0x3:  
00d6762c 8bec   mov ebp,esp    
00d6762e 56   push esi  
00d6762f 68a8000000 **push 0A8h**     //asking for 0xA8   
00d67634 be0e000780 mov esi,8007000Eh   
00d67639 e845a0edff call IEFRAME!operator new (00c41683)   
00d6763e 85c0   test eax,eax  
00d67640 59 pop ecx  
00d67641 7419 je IEFRAME!CIntShcut_CreateInstance+0x23 (00d6765c)  

IEFRAME!CIntShcut_CreateInstance+0x15:  
00d6763e 85c0 test eax,eax  
0:008> !heap -p -a eax  

address 00247190 found in  
_HEAP @ 150000  
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state  
00246eb0 0400 0000 [01] 00246eb8 **01ff8** - (busy)  why 0x1FF8 ?? 

EFRAME!operator new: 
00c41683 8bff mov edi,edi  
00c41685 55 push ebp  
00c41686 8bec mov ebp,esp  
00c41688 ff7508 push dword ptr [ebp+8]  
00c4168b 6a08 push 8  
00c4168d ff153c11c300 call dword ptr [IEFRAME!imp_GetProcessHeap (00c3113c)]  
00c41693 50 push tax  
00c41694 ff153811c300 call dword ptr [IEFRAME!imp_HeapAlloc (00c31138)]  

答えて

2

ブロック、より多くのデバッグ)。

これは、割り当てごとにシステムコールからメモリを要求するのはコストがかかるため、ヒープの領域が不足して別のシステム割り当てが必要になるまで、はるかに大きなブロックが必要に応じて分割されます。ウィンドウヒープは、8バイトの複数のブロックの割り当てによってこれを行います。 the answer hereは、より詳細でwindbgの中で列を詳述しながら、

は、Windowsのメモリヒープの時より徹底的な一見のためのthisthisを参照してください。

+0

だから、 "!heap -a"はLFHで使用すると元の割り当てが表示されないと仮定します。 代わりに、LFHの内部割り当てが表示されます "...ビジー 元の割り当てをリストするオプションはありますか? – gamepe

+0

ページヒープを有効にできると仮定して元の割り当てを表示しますが、これを行う唯一の方法ですか? – gamepe

+0

http://windbg.info/doc/1-common-cmds.html#20_memory_heapには、 '!heap -p -all'を使って割り当てを列挙し、元のアドレスと同じようにアドレスを指定してくださいちょうどヒープでそれを見つけて、それが見つかったヒープについての詳細をリストします – Necrolis

関連する問題