Dalam Visual Studio C ++, apa representasi alokasi memori?

Dalam Visual Studio, kita semua memiliki "baadf00d", telah melihat "CC" dan "CD" ketika memeriksa variabel dalam debugger di C ++ selama run-time.

Dari apa yang saya mengerti, "CC" dalam mode DEBUG hanya untuk menunjukkan kapan memori baru () atau mengalokasikan () dan disatukan. Sedangkan "CD" mewakili memori yang dihapus atau yang bebas. Saya hanya melihat "baadf00d" di RELEASE build (tapi saya mungkin salah).

Sekali-sekali, kita masuk ke situasi mengatasi kebocoran memori, buffer overflows, dll dan informasi seperti ini sangat berguna.

Apakah seseorang akan berbaik hati untuk menunjukkan kapan dan dalam mode apa memori diatur ke pola byte yang dikenali untuk tujuan debugging?

Tautan ini memiliki informasi lebih lanjut:

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

* 0xABABABAB: Digunakan oleh Microsoft HeapAlloc () untuk menandai byte penjaga "no man's land" setelah mengalokasikan memori tumpukan
* 0xABADCAFE: Startup untuk nilai ini untuk menginisialisasi semua memori bebas untuk menangkap pointer yang salah
* 0xBAADF00D: Digunakan oleh Microsoft LocalAlloc (LMEM_FIXED) untuk menandai memori heal yang dialokasikan tidak diinisialisasi
* 0xBADCAB1E: Kode Kesalahan dikembalikan ke Microsoft eVC debugger ketika koneksi terputus ke debugger
* 0xBEEFCACE: Digunakan oleh Microsoft .NET sebagai angka ajaib dalam file sumber daya
* 0xCCCCCCCC: Digunakan oleh perpustakaan runtime debugging C ++ Microsoft untuk menandai memori stack yang belum diinisialisasi
* 0xCDCDCDCD: Digunakan oleh perpustakaan runtime debugging C ++ Microsoft untuk menandai memori tumpukan yang tidak diinisialisasi
* 0xDDDDDDDD: Digunakan oleh tumpukan debugging C ++ Microsoft untuk menandai memori tumpukan yang dibebaskan
* 0xDEADDEAD: Kode galat STOP Microsoft Windows yang digunakan saat pengguna memulai crash secara manual.
* 0xFDFDFDFD: Digunakan oleh tumpukan debugging C ++ Microsoft untuk menandai byte penjaga "no man's land" sebelum dan sesudah mengalokasikan memori tumpukan
* 0xFEEEFEEE: Digunakan oleh Microsoft HeapFree () untuk menandai memori heap yang dibebaskan

Sebenarnya ada sedikit informasi berguna yang ditambahkan ke alokasi debug. Tabel ini lebih lengkap:

http://www.nobugs.org/developer/win32/debug_crt_heap.html#table

Alamat Offset Setelah HeapAlloc () Setelah malloc () Selama bebas () Setelah HeapFree () Komentar
0x00320FD8 -40 0x01090009 0x01090009 0x01090009 0x0109005A Win32 info tumpukan
0x00320FDC -36 0x01090009 0x00180700 0x01090009 0x00110400 Win32 info tumpukan
0x00320FE0 -32 0xBAADF00D 0x00320798 0xDDDDDDDD 0x00320448 Ptr ke blok tumpukan CRT berikutnya (dialokasikan sebelumnya dalam waktu)
0x00320FE4 -28 0xBAADF00D 0x00000000 0xDDDDDDDD 0x00320448 Ptr untuk mencegah blok heap CRT (dialokasikan nanti dalam waktu)
0x00320FE8 -24 0xBAADF00D 0x00000000 0xDDDDDDDD 0xFEEEFEEE Nama file malloc () panggilan
0x00320FEC -20 0xBAADF00D 0x00000000 0xDDDDDDDD 0xFEEEFEEE Nomor baris panggilan malloc ()
0x00320FF0 -16 0xBAADF00D 0x00000008 0xDDDDDDDD 0xFEEEFEEE Jumlah byte ke malloc ()
0x00320FF4 -12 0xBAADF00D 0x00000001 0xDDDDDDDD 0xFEEEFEEE Jenis (0 = Dibebaskan, 1 = Normal, 2 = penggunaan CRT, dll)
0x00320FF8 -8 0xBAADF00D 0x00000031 0xDDDDDDDD 0xFEEEFEEE Permintaan #, meningkat dari 0
0x00320FFC -4 0xBAADF00D 0xFDFDFDFD 0xDDDDDDDD 0xFEEEFEEE Tidak ada lahan
0x00321000 +0 0xBAADF00D 0xCDCDCDCD 0xDDDDDDDD 0xFEEEFEEE 8 byte yang Anda inginkan
0x00321004 +4 0xBAADF00D 0xCDCDCDCD 0xDDDDDDDD 0xFEEEFEEE 8 byte yang Anda inginkan
0x00321008 +8 0xBAADF00D 0xFDFDFDFD 0xDDDDDDDD 0xFEEEFEEE Tidak ada lahan
0x0032100C +12 0xBAADF00D 0xBAADF00D 0xDDDDDDDD 0xFEEEFEEE Alokasi heap Win32 dibulatkan hingga 16 byte
0x00321010 +16 0xABABABAB 0xABABABAB 0xABABABAB 0xFEEEFEEE Win32 pembukuan tumpukan
0x00321014 +20 0xABABABAB 0xABABABAB 0xABABABAB 0xFEEEFEEE Win32 pembukuan tumpukan
0x00321018 +24 0x00000010 0x00000010 0x00000010 0xFEEEFEEE Win32 pembukuan tumpukan
0x0032101C +28 0x00000000 0x00000000 0x00000000 0xFEEEFEEE Win32 pembukuan tumpukan
0x00321020 +32 0x00090051 0x00090051 0x00090051 0xFEEEFEEE Win32 pembukuan tumpukan
0x00321024 +36 0xFEEE0400 0xFEEE0400 0xFEEE0400 0xFEEEFEEE Win32 pembukuan tumpukan
0x00321028 +40 0x00320400 0x00320400 0x00320400 0xFEEEFEEE Win32 pembukuan tumpukan
0x0032102C +44 0x00320400 0x00320400 0x00320400 0xFEEEFEEE Win32 pembukuan tumpukan

Mengenai 0xCCdan 0xCDkhususnya, ini adalah peninggalan dari Intel 8088 / 8086 instruksi prosesor set kembali pada 1980-an. 0xCCadalah kasus khusus dari opcode interupsi perangkat lunak . Versi byte tunggal khusus memungkinkan program untuk menghasilkan interrupt 3 .INT 0xCD0xCC

Meskipun angka interupsi perangkat lunak, pada prinsipnya, arbitrer, INT 3secara tradisional digunakan untuk fungsi debugger break atau breakpoint , sebuah konvensi yang masih ada hingga hari ini. Setiap kali debugger diluncurkan, ia menginstal interrupt handler untuk INT 3sedemikian rupa sehingga ketika opcode dijalankan, debugger akan terpicu. Biasanya itu akan menghentikan sementara pemrograman yang sedang berjalan dan menampilkan prompt interaktif.

Biasanya, INTopcode x86 adalah dua byte: 0xCDdiikuti oleh angka interupsi yang diinginkan dari 0-255. Sekarang meskipun Anda bisa mengeluarkan 0xCD 0x03untuk INT 3, Intel memutuskan untuk menambahkan khusus sebuah version-- 0xCCtanpa byte tambahan - karena opcode harus hanya satu byte untuk fungsi sebagai 'mengisi byte' yang handal untuk memori yang tidak terpakai.

Intinya di sini adalah untuk memungkinkan pemulihan yang anggun jika prosesor keliru melompat ke memori yang tidak mengandung instruksi yang dimaksud . Instruksi multi-byte tidak cocok untuk tujuan ini karena lompatan yang salah dapat mendarat pada byte byte yang mungkin di mana ia harus melanjutkan dengan aliran instruksi yang dibentuk dengan benar.

Jelas, satu-byte opcodes bekerja sepele untuk ini, tetapi bisa juga ada pengecualian unik: misalnya, mengingat urutan pengisian 0xCDCDCDCD(juga disebutkan pada halaman ini), kita dapat melihat bahwa itu cukup dapat diandalkan karena di mana pun penunjuk instruksi mendarat ( kecuali mungkin byte terisi terakhir), CPU dapat melanjutkan mengeksekusi instruksi dua-byte x86 yang valid CD CD, dalam hal ini untuk menghasilkan interupsi perangkat lunak 205 (0xCD).

Lebih aneh lagi, sedangkan CD CC CD CC100% dapat ditafsirkan - memberikan salah satu INT 3atau INT 204- urutan CC CD CC CDkurang dapat diandalkan, hanya 75% seperti yang ditunjukkan, tetapi umumnya 99,99% ketika diulang sebagai pengisi memori ukuran int.

_{Referensi Makro Assembler , 1987}