0

why the operator new return 0x1ff8 when it been asked to allocate 0xA8 bytes?

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)]    
trincot
  • 317,000
  • 35
  • 244
  • 286
gamepe
  • 1
  • 2

1 Answers1

2

That is the size of the heap's memory pool(s), not the size of the single allocation made to your program (though the requested size will be a little bigger as certain overhead is added to each requested memory block, more so in debug more).

This is because it is expensive to request memory from the system calls for every allocation, so instead much bigger blocks are requested then partitioned off as needed, till the heap runs out of space an requires another system allocation. The windows heap does this by allocation multiple blocks of 8 bytes.

See this and this for a more indepth look at Windows memory heap's, while the answer here details the columns in windbg with more detail.

Community
  • 1
  • 1
Necrolis
  • 25,836
  • 3
  • 63
  • 101
  • so i assume that "!heap -a" when used upon LFH will not show original allocation. Instead the LFH internal allocations are shown "...Busy Is there any option to list original allocations? – gamepe Mar 08 '12 at 07:45
  • i assume i can enable page heap and it will show the original allocation but is it the only way to do so ? – gamepe Mar 08 '12 at 08:01
  • according to http://windbg.info/doc/1-common-cmds.html#20_memory_heap , you should just be able to use `!heap -p -all` to list the allocations, supplying the address as you did in your original just finds it in the heap then lists details about the heap in which it was found – Necrolis Mar 08 '12 at 08:40
  • i gave the -p -all a try and i saw it is still show up 0x HEAP_ENTRY Size Prev Flags UserPtr UserSize - state 00150680 0301 0000 [01] 00150688 01800 - (busy) 00151e88 0080 0301 [01] 00151e90 01ff8 - (busy) – gamepe Mar 08 '12 at 11:43
  • i actually found a way which is to enable Create user mode stack trace database on the application ==LFH disabled . – gamepe Mar 08 '12 at 12:39