Visual Studioでは、実行中にC++のデバッガーで変数を検査すると、「baadf00d」があり、「CC」と「CD」が表示されていました。
私が理解していることから、「CC」は、メモリがnew()またはalloc()でユニタリ化されたことを示すためだけにDEBUGモードになっています。 「CD」は削除または解放されたメモリを表します。 RELEASEビルドでは「baadf00d」しか見ていません(ただし、間違っている可能性があります)。
時々、メモリリーク、バッファオーバーフローなどに対処する状況に陥り、これらの種類の情報が役立ちます。
デバッグの目的でメモリが認識可能なバイトパターンに設定されている時期とモードを指摘できるほど親切な人がいますか?
このリンクには詳細情報があります。
http://en.wikipedia.org/wiki/Magic_number_(programming)
* 0xABABABAB:MicrosoftのHeapAlloc()が、ヒープメモリを割り当てた後に "no man's land"ガードバイトをマークするために使用します。 .____。] * 0xBAADF00D:MicrosoftのLocalAlloc(LMEM_FIXED)が初期化されていない割り当て済みヒープメモリをマークするために使用します。 :Microsoft .NETがリソースファイルのマジックナンバーとして使用します。 * 0xCCCCCCCC:MicrosoftのC++デバッグランタイムライブラリが初期化されていないスタックメモリをマークするために使用します *初期化されていないヒープメモリ * 0xDDDDDDDD:解放されたヒープメモリをマークするためにMicrosoftのC++デバッグヒープによって使用されます * 0xDEADDEAD:ユーザーが手動でクラッシュを開始するときに使用されるMicrosoft Windows STOPエラーコード。 * 0xFDFDFDFD:MicrosoftのC++デバッグヒープがマークするために使用"no man's land"割り当てられたヒープメモリの前後のガードバイト * 0xFEEEFEEE:MicrosoftのHeapFree()が空きヒープメモリをマークするために使用します
実際には、割り当てをデバッグするためにかなり多くの有用な情報が追加されています。この表はより完全です:
http://www.nobugs.org/developer/win32/debug_crt_heap.html#table
HeapAlloc()後のアドレスオフセットmalloc()後free()中HeapFree()の後コメント 0x00320FD8 -40 0x01090009 0x01090009 0x01090009 0x0109005A Win32ヒープ情報 0x00320FDC -36 0x01090009 0x00180700 0x00180400 Win32ヒープ情報 0x00320FE0 -32 0xBAADF00D 0x00320798 0xDDDDDDDD 0x00320448次のCRTヒープブロックへのPtr(時間的に早く割り当てられます) 0x00320FE4 -28 0xBAADF00D 0x00000000 0xDDDDDDtr0al time) 0x00320FE8 -24 0xBAADF00D 0x00000000 0xDDDDDDDD 0xFEEEFEEE malloc()呼び出しのファイル名 0x00320FEC -20 0xBAADF00D 0x00000000 0xDDDDDDDD 0xFEEEFEEE 0xFEEEFEEE malloc() へのバイト数0x00320FF4 -12 0xBAADF00D 0x00000001 0xDDDDDDDD 0xFEEEFEEEタイプ(0 =解放、1 =通常、2 = CRT使用など) 0x00320FF8 -8 0xBAADF00D 0x00000031 0xDDDDDDDD 0xFEEEFEEE要求番号、0 0x00320FFC -4から増加します0xBAADF00D 0xFDFDFDFD 0xDDDDDDDD 0xFEEEFEEE_______ ] 0x00321000 +0 0xBAADF00D 0xCDCDCDCD 0xDDDDDDDD 0xFEEEFEEE希望の8バイト 0x00321004 +4 0xBAADF00D 0xCDCDCDCD 0xDDDDDDDD 0xFEEEFEEE希望の8バイト 0x0032100C +12 0xBAADF00D 0xBAADF00D 0xDDDDDDDD 0xFEEEFEEE Win32ヒープ割り当ては、16バイトに切り上げられます 0x00321010 +16 0xABABABAB 0xFEEEFEABABx xxABABABAB x ] 0x00321018 +24 0x00000010 0x00000010 0x00000010 0xFEEEFEEE Win32ヒープブックkeeping 0x0032101C +28 0x00000000 0x00000000 0x00000000 0xFEEEFEEE Win32ヒープブックキーピング 0x00321020 +32 0x00090051 0x00090051 0x00090051 0xFEEEFEEE Win32ヒープブックキーピング[.____。0FEEEEE4000EEEE4000EEEE0400EEEE0400EEEE400EEE0400EEEE400EEE0400EEEE400EEE0400EEEE400EEE0400EEEE400EEE0400EE ] 0x00321028 +40 0x00320400 0x00320400 0x00320400 0xFEEEFEEE Win32ヒープブックキーピング 0x0032102C +44 0x00320400 0x00320400 0x00320400 0xFEEEFEEE Win32ヒープブックキーピング
特に0xCC
と0xCD
に関しては、これらはIntel 8088 / 80861980年代に戻ったプロセッサ命令。 0xCC
は、 ソフトウェア割り込み opcode INT
0xCD
の特殊なケースです。特別なシングルバイトバージョン0xCC
を使用すると、プログラムはinterrupt 3を生成できます。
ソフトウェア割り込み番号は、原則として任意ですが、伝統的にdebugger breakまたは breakpoint にINT 3
が使用されていました機能、今日まで残っている慣習。デバッガーが起動されるたびに、INT 3
の割り込みハンドラーがインストールされ、そのオペコードが実行されるとデバッガーがトリガーされます。通常、現在実行中のプログラミングを一時停止し、インタラクティブなプロンプトを表示します。
通常、x86 INT
オペコードは2バイトです。0xCD
の後に0-255の目的の割り込み番号が続きます。 0xCD 0x03
に対してINT 3
を発行できるようになりましたが、Intelは特別なバージョンを追加することを決定しました--0xCC
は追加バイトなしで-機能するためにオペコードは1バイトでなければならないためです未使用メモリの信頼できる「フィルバイト」。
ここでのポイントは、プロセッサが意図した命令を含まないメモリに誤ってジャンプした場合にグレースフルリカバリを許可することです。誤ったジャンプは、適切に形成された命令ストリームを続行する必要がある可能性のあるバイトオフセットに到達する可能性があるため、マルチバイト命令はこの目的には適していません。
明らかに、これには1バイトのオペコードが簡単に機能しますが、風変わりな例外もあります。たとえば、フィルシーケンス0xCDCDCDCD
(このページでも説明します)を考慮すると、どこにいてもかなり信頼できることがわかります。 命令ポインター 土地(おそらく最後に埋められたバイトを除く)、CPUは有効なtwo- bytex86命令CD CD
。この場合、ソフトウェア割り込み205(0xCD)を生成します。
奇妙なことに、CD CC CD CC
は100%解釈可能です-INT 3
またはINT 204
のいずれかを与える-シーケンスCC CD CC CD
は信頼性が低く、示されているように75%だけですが、通常は99.99 intサイズのメモリフィラーとして繰り返される場合の%。