注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

一路

To find the final symmetry & beauty

 
 
 

日志

 
 
 
 

WFC Technical Note 006 - Funny Memory Values[quote]  

2010-11-07 00:31:33|  分类: 共享 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

Introduction

Microsoft has put quite a lot of memory leak detection helpers in Windows NT. They have not done a good job of advertising it. This document describes some of the things I've deciphered while debugging code.

Funny Memory Values

Many times while debugging programs, I will come across memory that is filled with "funny" values. After some playing around (i.e. hacking) with the Win32 API, I was able to figure out what they meant. Some of these values have been documented in places but never all together. The values for the tags presented here are hexadecimal because that's the way Developer's Studio presents them in the memory window.

 Value 

 Meaning 

 0xAB 
or
 0xABAB 
or
 0xABABABAB 

 Memory following a block allocated by LocalAlloc()

 0xBAADF00D 

 Bad Food. Get it? This is memory allocated via LocalAlloc( LMEM_FIXED, ... ). It is memory that has been allocated but not yet written to. 

 0xFEEE 
 0xFEEEFEEE 

 This seems to be memory that has been dedicated to a heap but not yet allocated by HeapAlloc() or LocalAlloc()

 0xCC 
or
 0xCCCC 
or
 0xCCCCCCCC 

 Microsoft Visual C++ compiled code with the /GZ is automatically initialized the uninitialized variable with this value. 

 0xCD 
or
 0xCDCD 
or
 0xCDCDCDCD 

 Microsoft Visual C++ compiled code with memory leak detection turned on. Usually, DEBUG_NEW was defined. Memory with this tag signifies memory that has been allocated (by malloc() or new) but never written to the application. 

 0xDD 
or
 0xDDDD 
or
 0xDDDDDDDD 

 Microsoft Visual C++ compiled code with memory leak detection turned on. Usually, DEBUG_NEW was defined. Memory with this tag signifies memory that has been freed (by free() or delete) by the application. It is how you can detect writing to memory that has already been freed. For example, if you look at an allocated memory structure (or C++ class) and most of the members contain this tag value, you are probably writing to a structure that has been freed. 

 0xFD 
or
 0xFDFD 
or
 0xFDFDFDFD 

 Microsoft Visual C++ compiled code with memory leak detection turned on. Usually, DEBUG_NEW was defined. Memory with this tag signifies memory that is in "no-mans-land." These are bytes just before and just after an allocated block. They are used to detect array-out-of-bounds errors. This is great for detecting off-by-one errors. 

   

   

Samuel R. Blackburn

   

http://www.samblackburn.com/wfc/technotes/WTN006.htm

   

   

http://en.wikipedia.org/wiki/Magic_number_(programming)

Magic debug values are specific values written to memory during allocation or deallocation, so that it will later be possible to tell whether or not they have become corrupted, and to make it obvious when values taken from uninitialized memory are being used.

Since it is unlikely that any given 32-bit integer would take this specific value, the appearance of such a number in a debugger or memory dump can indicate common errors such as buffer overflows, or uninitialized variables.

Memory is usually viewed in hexadecimal, so common values used are often repeated digits or hexspeak.

Famous and common examples include:

  • 0x5F3759DF : Used in Quake 3 for an optimized inverse square root function. [8]
  • 0x..FACADE : Used by a number of RTOSes
  • 0xA5A5A5A5 : Used in embedded development because the alternating bit pattern (10100101) creates an easily recognized pattern on oscilloscopes and logic analyzers.
  • 0xABABABAB : Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory
  • 0xABADBABE : Used by Apple as the "Boot Zero Block" magic number
  • 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
  • 0xBADBADBADBAD : Burroughs large systems "uninitialized" memory (48-bit words)
  • 0xBADCAB1E : Error Code returned to the Microsoft eVC debugger when connection is severed to the debuggee
  • 0xBADC0FFEE0DDF00D : Used on IBM RS/6000 64-bit systems to indicate uninitialized CPU registers
  • 0xBADDCAFE : On Sun Microsystems' Solaris, marks uninitialised kernel memory (KMEM_UNINITIALIZED_PATTERN)
  • 0xBEEFCACE : Used by Microsoft .NET as a magic number in resource files
  • 0xC0DEDBAD : A memory leak tracking tool which it will change the MMU tables so that all references to address zero
  • 0xCAFEBABE : Used by both Mach-O ("Fat binary" in both 68k and PowerPC) to identify object files and the Java programming language to identify .class files
  • 0xCAFEFEED : Used by Sun Microsystems' Solaris debugging kernel to mark kmemfree() memory
  • 0xCEFAEDFE : Seen in Intel Mach-O binaries on Apple Computer's Mac OS X platform (see 0xFEEDFACE below)
  • 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 MicroQuill's SmartHeap and Microsoft's C++ debugging heap to mark freed heap memory
  • 0xDEADBABE : Used at the start of Silicon Graphics' IRIX arena files
  • 0xDEADBEEF : Famously used on IBM systems such as the RS/6000, also used in the original Mac OS operating systems, OPENSTEP Enterprise, and the Commodore Amiga. On Sun Microsystems' Solaris, marks freed kernel memory (KMEM_FREE_PATTERN)
  • 0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually initiates the crash.
  • 0xDEADF00D : All the newly allocated memory which is not explicitly cleared when it is munged
  • 0xEBEBEBEB : From MicroQuill's SmartHeap
  • 0xFADEDEAD : Comes at the end to identify every OSA script
  • 0xFDFDFDFD : Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory
  • 0xFEEDFACE : Seen in PowerPC Mach-O binaries on Apple Computer's Mac OS X platform. On Sun Microsystems' Solaris, marks the red zone (KMEM_REDZONE_PATTERN)
  • 0xFEEEFEEE : Used by Microsoft's HeapFree() to mark freed heap memory
  • 0xFEE1DEAD : Used by Linux reboot() syscall

Note that most of these are each 32 bits long — the word size of most modern computers.

The prevalence of these values in Microsoft technology is no coincidence; they are discussed in detail in Steve Maguire's book Writing Solid Code from Microsoft Press. He gives a variety of criteria for these values, such as:

  • They should not be useful; that is, most algorithms that operate on them should be expected to do something unusual. Numbers like zero don't fit this criterion.
  • They should be easily recognized by the programmer as invalid values in the debugger.
  • On machines that don't have byte alignment, they should be odd numbers, so that dereferencing them as addresses causes an exception.
  • They should cause an exception, or perhaps even a debugger break, if executed as code.

Since they were often used to mark areas of memory that were essentially empty, some of these terms came to be used in phrases meaning "gone, aborted, flushed from memory"; e.g. "Your program is DEADBEEF".

Pietr Brandeh?rst's ZUG programming language initialized memory to either 0x0000, 0xDEAD or 0xFFFF in development environment and to 0x0000 in the live environment, on the basis that uninitialised variables should be encouraged to misbehave under development to trap them, but encouraged to behave in a live environment to reduce errors

  评论这张
 
阅读(783)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017