No Visual Studio C ++, quais são as representações de alocação de memory?

No Visual Studio, todos nós tivemos “baadf00d”, vimos “CC” e “CD” ao inspecionar variables ​​no depurador em C ++ durante o tempo de execução.

Pelo que entendi, “CC” está no modo DEBUG apenas para indicar quando uma memory foi new () ou alloc () e unitilialized. Enquanto “CD” representa memory deletada ou livre. Eu só vi “baadf00d” em construir RELEASE (mas eu posso estar errado).

De vez em quando, entramos em uma situação de vazamentos de memory, buffer overflows, etc, e esse tipo de informação é útil.

Alguém seria gentil o bastante para apontar quando e em quais modos a memory é configurada para padrões de bytes reconhecíveis para fins de debugging?

Este link tem mais informações:

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

 * 0xABABABAB: usado pelo HeapAlloc () da Microsoft para marcar os bytes de proteção "land de ninguém" após a memory de heap alocada
 * 0xABADCAFE: Uma boot para este valor para inicializar toda a memory livre para capturar pointers errantes
 * 0xBAADF00D: usado pelo LocalAlloc da Microsoft (LMEM_FIXED) para marcar a memory heap alocada não inicializada
 * 0xBADCAB1E: Código de erro retornado ao depurador Microsoft eVC quando a conexão é cortada no depurador
 * 0xBEEFCACE: usado pelo Microsoft .NET como um número mágico em arquivos de resources
 * 0xCCCCCCCC: Usado pela biblioteca de tempo de execução de debugging C ++ da Microsoft para marcar memory de pilha não inicializada
 * 0xCDCDCDCD: Usado pela biblioteca de tempo de execução de debugging C ++ da Microsoft para marcar memory heap não inicializada
 * 0xDDDDDDDD: Usado pelo heap de debugging C ++ da Microsoft para marcar memory de heap livre
 * 0xDEADDEAD: Um código de erro do Microsoft Windows STOP usado quando o usuário inicia manualmente a falha.
 * 0xFDFDFDFD: Usado pelo heap de debugging C ++ da Microsoft para marcar os bytes de proteção "land de ninguém" antes e depois da memory heap alocada
 * 0xFEEEFEEE: usado pelo HeapFree () da Microsoft para marcar memory heap livre

Na verdade, há bastante informação útil adicionada para depurar as alocações. Esta tabela é mais completa:

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

 Deslocamento de endereço após HeapAlloc () Depois malloc () durante livre () após HeapFree () Comentários
 0x00320FD8 -40 0x01090009 0x01090009 0x01090009 0x0109005A Informações de heap Win32
 0x00320FDC -36 0x01090009 0x00180700 0x01090009 0x00180400 Informações de heap Win32
 0x00320FE0 -32 0xBAADF00D 0x00320798 0xDDDDDDDD 0x00320448 Ptr para o próximo bloco de heap CRT (alocado antecipadamente no tempo)
 0x00320FE4 -28 0xBAADF00D 0x00000000 0xDDDDDDDD 0x00320448 Ptr para o bloco de heap CRT anterior (alocado posteriormente no tempo)
 0x00320FE8 -24 0xBAADF00D 0x00000000 0xDDDDDDDD 0xFEEEFEEE Nome do arquivo da chamada malloc ()
 0x00320FEC -20 0xBAADF00D 0x00000000 0xDDDDDDDD 0xFEEEFEEE Número de linha da chamada malloc ()
 0x00320FF0 -16 0xBAADF00D 0x00000008 0xDDDDDDDD 0xFEEEFEEE Número de bytes para malloc ()
 0x00320FF4 -12 0xBAADF00D 0x00000001 0xDDDDDDDD 0xFEEEFEEE Tipo (0 = Livre, 1 = Normal, 2 = uso de CRT, etc)
 0x00320FF8 -8 0xBAADF00D 0x00000031 0xDDDDDDDD 0xFEEEFEEE Request #, aumenta de 0
 0x00320FFC -4 0xBAADF00D 0xFDFDFDFD 0xDDDDDDDD 0xFEEEFEEE Nenhuma terra do homem
 0x00321000 +0 0xBAADF00D 0xCDCDCDCD 0xDDDDDDDD 0xFEEEFEEE Os 8 bytes desejados
 0x00321004 +4 0xBAADF00D 0xCDCDCDCD 0xDDDDDDDD 0xFEEEFEEE Os 8 bytes desejados
 0x00321008 +8 0xBAADF00D 0xFDFDFDFD 0xDDDDDDDD 0xFEEEFEEE Nenhuma terra do homem
 0x0032100C +12 0xBAADF00D 0xBAADF00D 0xDDDDDDDD 0xFEEEFEEE As alocações de heap Win32 são arredondadas para 16 bytes
 0x00321010 +16 0xABABABAB 0xABABABAB 0xABABABAB 0xFEEEFEEE Contabilidade de heap do Win32
 0x00321014 +20 0xABABABAB 0xABABABAB 0xABABABAB 0xFEEEFEEE Contabilidade de heap do Win32
 0x00321018 +24 0x00000010 0x00000010 0x00000010 0xFEEEFEEE Contabilidade de heap do Win32
 0x0032101C +28 0x00000000 0 x 00000000 0 x 00000000 0xFEEEFEEE Contabilidade de heap do Win32
 0x00321020 +32 0x00090051 0x00090051 0x00090051 0xFEEEFEEE Contabilidade de heap do Win32
 0x00321024 +36 0xFEEE0400 0xFEEE0400 0xFEEE0400 0xFEEEFEEE Contabilidade de heap do Win32
 0x00321028 +40 0x00320400 0x00320400 0x00320400 0xFEEEFEEE Contabilidade de heap do Win32
 0x0032102C +44 0x00320400 0x00320400 0x00320400 0xFEEEFEEE Contabilidade de heap do Win32

Com relação a 0xCC e 0xCD em particular, estas são relíquias da instrução do processador Intel 8088/8086 retrocedida nos anos 80. 0xCC é um caso especial do opcode de interrupção de software INT 0xCD . A versão especial de um único byte 0xCC permite que um programa gere a interrupção 3 .

Embora os números de interrupção de software sejam, em princípio, arbitrários, a INT 3 era tradicionalmente usada para a quebra de depurador ou function de ponto de interrupção , uma convenção que permanece até hoje. Sempre que um depurador é iniciado, ele instala um manipulador de interrupções para o INT 3 modo que quando esse opcode é executado, o depurador será acionado. Normalmente, irá pausar a programação atualmente em execução e mostrar um prompt interativo.

Normalmente, o opcode x86 INT é de dois bytes: 0xCD seguido do número de interrupção desejado de 0-255. Agora, embora você possa emitir 0xCD 0x03 para INT 3 , a Intel decidiu adicionar uma 0xCC especial – 0xCC sem byte adicional – porque um opcode deve ser de apenas um byte para funcionar como um ‘byte de preenchimento’ confiável para a memory não utilizada.

O ponto aqui é permitir uma recuperação elegante se o processador erroneamente pular na memory que não contém nenhuma instrução pretendida . Instruções multi-byte não são adequadas a este propósito, já que um salto errôneo poderia pousar em qualquer offset de byte possível, onde ele teria que continuar com um stream de instrução adequadamente formado.

Obviamente, opcodes de um byte funcionam trivialmente para isso, mas também pode haver exceções peculiares: por exemplo, considerando a sequência de preenchimento 0xCDCDCDCD (também mencionada nesta página), podemos ver que ela é bastante confiável, já que não importa onde o ponteiro de instrução está (exceto talvez o último byte preenchido), a CPU pode retomar a execução de um CD CD instruções x86 de dois bytes válido, neste caso, para gerar a interrupção de software 205 (0xCD).

Mais estranho ainda, enquanto CD CC CD CC é 100% interpretável – dando INT 3 ou INT 204 – a sequência CC CD CC CD é menos confiável, apenas 75% como mostrado, mas geralmente 99,99% quando repetido como um int-sized preenchimento de memory.

página do manual do conjunto de instruções 8088/8086 contemporâneo mostrando a instrução INT
Macro Assembler Reference , 1987