In Visual Studio C what are the memory allocation representations

Question

In Visual Studio  we ve all had  baadf00d   have seen seen  CC  and  CD  when inspecting variables in the debugger in C   during run-time   From what I understand   CC  is in DEBUG mode only to indicate when a memory has been new   or alloc   and unitilialized   While  CD  represents delete d or free d memory   I ve only seen  baadf00d  in RELEASE build  but I may be wrong    Once in a while  we get into a situation of tacking memory leaks  buffer overflows  etc and these kind of information comes in handy   Would somebody be kind enough to point out when and in what modes the memory are set to recognizable byte patterns for debugging purpose

User · Answer

There s actually quite a bit of useful information added to debug allocations   This table is more complete   http   www nobugs org developer win32 debug crt heap html table   Address  Offset After HeapAlloc   After malloc   During free   After HeapFree   Comments 0x00320FD8  -40    0x01090009    0x01090009     0x01090009    0x0109005A     Win32 heap info 0x00320FDC  -36    0x01090009    0x00180700     0x01090009    0x00180400     Win32 heap info 0x00320FE0  -32    0xBAADF00D    0x00320798     0xDDDDDDDD    0x00320448     Ptr to next CRT heap block  allocated earlier in time  0x00320FE4  -28    0xBAADF00D    0x00000000     0xDDDDDDDD    0x00320448     Ptr to prev CRT heap block  allocated later in time  0x00320FE8  -24    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Filename of malloc   call 0x00320FEC  -20    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Line number of malloc   call 0x00320FF0  -16    0xBAADF00D    0x00000008     0xDDDDDDDD    0xFEEEFEEE     Number of bytes to malloc   0x00320FF4  -12    0xBAADF00D    0x00000001     0xDDDDDDDD    0xFEEEFEEE     Type  0 Freed  1 Normal  2 CRT use  etc  0x00320FF8  -8     0xBAADF00D    0x00000031     0xDDDDDDDD    0xFEEEFEEE     Request    increases from 0 0x00320FFC  -4     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land 0x00321000   0     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted 0x00321004   4     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted 0x00321008   8     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land 0x0032100C   12    0xBAADF00D    0xBAADF00D     0xDDDDDDDD    0xFEEEFEEE     Win32 heap allocations are rounded up to 16 bytes 0x00321010   16    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping 0x00321014   20    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping 0x00321018   24    0x00000010    0x00000010     0x00000010    0xFEEEFEEE     Win32 heap bookkeeping 0x0032101C   28    0x00000000    0x00000000     0x00000000    0xFEEEFEEE     Win32 heap bookkeeping 0x00321020   32    0x00090051    0x00090051     0x00090051    0xFEEEFEEE     Win32 heap bookkeeping 0x00321024   36    0xFEEE0400    0xFEEE0400     0xFEEE0400    0xFEEEFEEE     Win32 heap bookkeeping 0x00321028   40    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping 0x0032102C   44    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping

User · Answer

There s actually quite a bit of useful information added to debug allocations   This table is more complete   http   www nobugs org developer win32 debug crt heap html table   Address  Offset After HeapAlloc   After malloc   During free   After HeapFree   Comments 0x00320FD8  -40    0x01090009    0x01090009     0x01090009    0x0109005A     Win32 heap info 0x00320FDC  -36    0x01090009    0x00180700     0x01090009    0x00180400     Win32 heap info 0x00320FE0  -32    0xBAADF00D    0x00320798     0xDDDDDDDD    0x00320448     Ptr to next CRT heap block  allocated earlier in time  0x00320FE4  -28    0xBAADF00D    0x00000000     0xDDDDDDDD    0x00320448     Ptr to prev CRT heap block  allocated later in time  0x00320FE8  -24    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Filename of malloc   call 0x00320FEC  -20    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Line number of malloc   call 0x00320FF0  -16    0xBAADF00D    0x00000008     0xDDDDDDDD    0xFEEEFEEE     Number of bytes to malloc   0x00320FF4  -12    0xBAADF00D    0x00000001     0xDDDDDDDD    0xFEEEFEEE     Type  0 Freed  1 Normal  2 CRT use  etc  0x00320FF8  -8     0xBAADF00D    0x00000031     0xDDDDDDDD    0xFEEEFEEE     Request    increases from 0 0x00320FFC  -4     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land 0x00321000   0     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted 0x00321004   4     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted 0x00321008   8     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land 0x0032100C   12    0xBAADF00D    0xBAADF00D     0xDDDDDDDD    0xFEEEFEEE     Win32 heap allocations are rounded up to 16 bytes 0x00321010   16    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping 0x00321014   20    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping 0x00321018   24    0x00000010    0x00000010     0x00000010    0xFEEEFEEE     Win32 heap bookkeeping 0x0032101C   28    0x00000000    0x00000000     0x00000000    0xFEEEFEEE     Win32 heap bookkeeping 0x00321020   32    0x00090051    0x00090051     0x00090051    0xFEEEFEEE     Win32 heap bookkeeping 0x00321024   36    0xFEEE0400    0xFEEE0400     0xFEEE0400    0xFEEEFEEE     Win32 heap bookkeeping 0x00321028   40    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping 0x0032102C   44    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping

User · Answer

This link has more information  https   en wikipedia org wiki Magic number  programming  Debug values    0xABABABAB   Used by Microsoft s HeapAlloc   to mark  no man s land  guard bytes after allocated heap memory   0xABADCAFE   A startup to this value to initialize all free memory to catch errant pointers   0xBAADF00D   Used by Microsoft s LocalAlloc LMEM FIXED  to mark uninitialised allocated heap memory   0xBADCAB1E   Error Code returned to the Microsoft eVC debugger when connection is severed to the debugger   0xBEEFCACE   Used by Microsoft  NET as a magic number in resource files   0xCCCCCCCC   Used by Microsoft s C   debugging runtime library to mark uninitialised stack memory   0xCDCDCDCD   Used by Microsoft s C   debugging runtime library to mark uninitialised heap memory   0xDDDDDDDD   Used by Microsoft s C   debugging heap to mark freed heap memory   0xDEADDEAD   A Microsoft Windows STOP Error code used when the user manually initiates the crash    0xFDFDFDFD   Used by Microsoft s C   debugging heap to mark  no man s land  guard bytes before and after allocated heap memory   0xFEEEFEEE   Used by Microsoft s HeapFree   to mark freed heap memory

User · Answer

Regarding 0xCC and 0xCD in particular  these are relics from the Intel 8088 8086 processor instruction set back in the 1980s  0xCC is a special case of the software interrupt opcode  INT 0xCD  The special single-byte version 0xCC allows a program to generate interrupt 3   Although software interrupt numbers are  in principle  arbitrary  INT 3 was traditionally used for the debugger break or breakpoint function  a convention which remains to this day  Whenever a debugger is launched  it installs an interrupt handler for INT 3 such that when that opcode is executed the debugger will be triggered  Typically it will pause the currently running programming and show an interactive prompt   Normally  the x86 INT opcode is two bytes  0xCD followed by the desired interrupt number from 0-255  Now although you could issue 0xCD 0x03 for INT 3  Intel decided to add a special version--0xCC with no additional byte--because an opcode must be only one byte in order to function as a reliable  fill byte  for unused memory   The point here is to allow for graceful recovery if the processor mistakenly jumps into memory that does not contain any intended instructions  Multi-byte instructions aren t suited this purpose since an erroneous jump could land at any possible byte offset where it would have to continue with a properly formed instruction stream   Obviously  one-byte opcodes work trivially for this  but there can also be quirky exceptions  for example  considering the fill sequence 0xCDCDCDCD  also mentioned on this page   we can see that it s fairly reliable since no matter where the instruction pointer lands  except perhaps the last filled byte   the CPU can resume executing a valid two-byte x86 instruction CD CD  in this case for generating software interrupt 205  0xCD    Weirder still  whereas CD CC CD CC is 100  interpretable--giving either INT 3 or INT 204--the sequence CC CD CC CD is less reliable  only 75  as shown  but generally 99 99  when repeated as an int-sized memory filler    Macro Assembler Reference  1987

[debugging] In Visual Studio C++, what are the memory allocation representations?

Examples related to debugging

Examples related to visual-c++