Quando e por que um compilador inicializará a memória em 0xCD, 0xDD, etc. em malloc / free / new / delete?

Eu sei que o compilador às vezes inicializa a memória com certos padrões como 0xCDe 0xDD. O que eu quero saber é quando e por que isso acontece.

Quando

Isso é específico para o compilador usado?

Faça malloc/newe free/deletetrabalhe da mesma maneira com relação a isso?

É plataforma específica?

Isso ocorrerá em outros sistemas operacionais, como Linuxou VxWorks?

Por quê

Meu entendimento é que isso ocorre apenas na Win32configuração de depuração e é usado para detectar excedentes de memória e ajudar o compilador a capturar exceções.

Você pode dar exemplos práticos de como essa inicialização é útil?

Lembro-me de ler algo (talvez no Código Completo 2) dizendo que é bom inicializar a memória para um padrão conhecido ao alocá-lo, e determinados padrões acionarão interrupções nas Win32quais resultarão exceções exibidas no depurador.

Quão portátil é isso?

Um rápido resumo do que os compiladores da Microsoft usam para vários bits de memória não proprietária / não inicializada quando compilados no modo de depuração (o suporte pode variar de acordo com a versão do compilador):

Value     Name           Description 
------   --------        -------------------------
0xCD     Clean Memory    Allocated memory via malloc or new but never 
                         written by the application. 

0xDD     Dead Memory     Memory that has been released with delete or free. 
                         It is used to detect writing through dangling pointers. 

0xED or  Aligned Fence   'No man's land' for aligned allocations. Using a 
0xBD                     different value here than 0xFD allows the runtime
                         to detect not only writing outside the allocation,
                         but to also identify mixing alignment-specific
                         allocation/deallocation routines with the regular
                         ones.

0xFD     Fence Memory    Also known as "no mans land." This is used to wrap 
                         the allocated memory (surrounding it with a fence) 
                         and is used to detect indexing arrays out of 
                         bounds or other accesses (especially writes) past
                         the end (or start) of an allocated block.

0xFD or  Buffer slack    Used to fill slack space in some memory buffers 
0xFE                     (unused parts of `std::string` or the user buffer 
                         passed to `fread()`). 0xFD is used in VS 2005 (maybe 
                         some prior versions, too), 0xFE is used in VS 2008 
                         and later.

0xCC                     When the code is compiled with the /GZ option,
                         uninitialized variables are automatically assigned 
                         to this value (at byte level). 


// the following magic values are done by the OS, not the C runtime:

0xAB  (Allocated Block?) Memory allocated by LocalAlloc(). 

0xBAADF00D Bad Food      Memory allocated by LocalAlloc() with LMEM_FIXED,but 
                         not yet written to. 

0xFEEEFEEE               OS fill heap memory, which was marked for usage, 
                         but wasn't allocated by HeapAlloc() or LocalAlloc(). 
                         Or that memory just has been freed by HeapFree(). 

Isenção de responsabilidade: a tabela é de algumas notas que tenho por aí - elas podem não estar 100% corretas (ou coerentes).

Muitos desses valores são definidos em vc / crt / src / dbgheap.c:

/*
 * The following values are non-zero, constant, odd, large, and atypical
 *      Non-zero values help find bugs assuming zero filled data.
 *      Constant values are good, so that memory filling is deterministic
 *          (to help make bugs reproducible).  Of course, it is bad if
 *          the constant filling of weird values masks a bug.
 *      Mathematically odd numbers are good for finding bugs assuming a cleared
 *          lower bit.
 *      Large numbers (byte values at least) are less typical and are good
 *          at finding bad addresses.
 *      Atypical values (i.e. not too often) are good since they typically
 *          cause early detection in code.
 *      For the case of no man's land and free blocks, if you store to any
 *          of these locations, the memory integrity checker will detect it.
 *
 *      _bAlignLandFill has been changed from 0xBD to 0xED, to ensure that
 *      4 bytes of that (0xEDEDEDED) would give an inaccessible address under 3gb.
 */

static unsigned char _bNoMansLandFill = 0xFD;   /* fill no-man's land with this */
static unsigned char _bAlignLandFill  = 0xED;   /* fill no-man's land for aligned routines */
static unsigned char _bDeadLandFill   = 0xDD;   /* fill free objects with this */
static unsigned char _bCleanLandFill  = 0xCD;   /* fill new objects with this */

Também existem algumas vezes em que o tempo de execução de depuração preencherá os buffers (ou partes de buffers) com um valor conhecido, por exemplo, o espaço 'folga' na std::stringalocação ou o buffer passado para fread(). Esses casos usam um valor com o nome _SECURECRT_FILL_BUFFER_PATTERN(definido em crtdefs.h). Não sei exatamente quando foi introduzido, mas estava no tempo de execução de depuração pelo menos no VS 2005 (VC ++ 8).

Inicialmente, o valor usado para preencher esses amortecedores era 0xFD- o mesmo valor usado para a terra de ninguém. No entanto, no VS 2008 (VC ++ 9), o valor foi alterado para 0xFE. Suponho que isso ocorra porque poderia haver situações em que a operação de preenchimento seria executada além do final do buffer, por exemplo, se o chamador passasse em um tamanho de buffer muito grande para fread(). Nesse caso, o valor 0xFDpode não desencadear a detecção dessa saturação, pois se o tamanho do buffer fosse muito grande em apenas um, o valor de preenchimento seria o mesmo que o valor da terra de ninguém usado para inicializar esse canário. Nenhuma mudança na terra de ninguém significa que a superação não seria notada.

Portanto, o valor de preenchimento foi alterado no VS 2008, para que esse caso alterasse o canário terrestre de ninguém, resultando na detecção do problema pelo tempo de execução.

Como outros observaram, uma das principais propriedades desses valores é que, se uma variável de ponteiro com um desses valores for des-referenciada, isso resultará em uma violação de acesso, pois em uma configuração padrão do Windows de 32 bits, os endereços do modo de usuário não ultrapassará 0x7fffffff.

Uma propriedade interessante sobre o valor de preenchimento 0xCCCCCCCC é que, na montagem x86, o opcode 0xCC é o int3 opcode, que é a interrupção do ponto de interrupção do software. Portanto, se você tentar executar o código na memória não inicializada preenchida com esse valor de preenchimento, atingirá imediatamente um ponto de interrupção e o sistema operacional permitirá que você anexe um depurador (ou interrompa o processo).

É compilador e específico do sistema operacional, o Visual studio define diferentes tipos de memória para diferentes valores, de modo que no depurador você possa ver facilmente se ultrapassou a memória malloced, uma matriz fixa ou um objeto não inicializado. Alguém postará os detalhes enquanto eu os pesquiso no Google ...

http://msdn.microsoft.com/en-us/library/974tc9t1.aspx

Não é o sistema operacional - é o compilador. Você também pode modificar o comportamento. Consulte a parte inferior desta postagem.

O Microsoft Visual Studio gera (no modo Debug) um binário que preenche previamente a memória da pilha com 0xCC. Ele também insere um espaço entre cada quadro de pilha para detectar estouros de buffer. Um exemplo muito simples de onde isso é útil está aqui (na prática, o Visual Studio detectaria esse problema e emitia um aviso):

...
   bool error; // uninitialised value
   if(something)
   {
      error = true;
   }
   return error;

Se o Visual Studio não pré-inicializar variáveis ​​para um valor conhecido, esse bug poderá ser difícil de encontrar. Com variáveis ​​pré-inicializadas (ou melhor, memória de pilha pré-inicializada), o problema é reproduzível a cada execução.

No entanto, há um pequeno problema. O valor que o Visual Studio usa é TRUE - qualquer coisa, exceto 0, seria. Na verdade, é bem provável que, quando você executa seu código no modo Release, as variáveis ​​unitializadas possam ser alocadas para uma parte da memória da pilha que contenha 0, o que significa que você pode ter um erro de variável unitializada que se manifesta apenas no modo Release.

Isso me incomodou, então escrevi um script para modificar o valor de pré-preenchimento editando diretamente o binário, permitindo-me encontrar problemas variáveis ​​não inicializados que só aparecem quando a pilha contém zero. Este script modifica apenas o pré-preenchimento da pilha; Nunca experimentei o pré-preenchimento de heap, embora isso seja possível. Pode envolver a edição da DLL em tempo de execução, talvez não.

Isso é específico para o compilador usado?

Na verdade, quase sempre é um recurso da biblioteca de tempo de execução (como a biblioteca de tempo de execução C). O tempo de execução geralmente está fortemente correlacionado com o compilador, mas existem algumas combinações que você pode trocar.

Acredito que no Windows, o heap de depuração (HeapAlloc etc.) também usa padrões de preenchimento especiais diferentes dos que vêm das implementações malloc e gratuitas na biblioteca de tempo de execução C de depuração. Portanto, também pode ser um recurso do sistema operacional, mas na maioria das vezes, é apenas a biblioteca de tempo de execução do idioma.

Malloc / new e free / delete funcionam da mesma maneira com relação a isso?

A parte de gerenciamento de memória de new e delete é geralmente implementada com malloc e free, portanto, a memória alocada com new e delete geralmente possui os mesmos recursos.

É plataforma específica?

Os detalhes são específicos do tempo de execução. Os valores reais usados ​​geralmente são escolhidos para não apenas parecer incomuns e óbvios ao se observar um dump hexadecimal, mas são projetados para ter certas propriedades que podem tirar proveito dos recursos do processador. Por exemplo, valores ímpares são frequentemente usados, pois podem causar uma falha de alinhamento. Valores grandes são usados ​​(em oposição a 0), porque causam atrasos surpreendentes se você fizer um loop em um contador não inicializado. No x86, 0xCC é uma int 3instrução; portanto, se você executar uma memória não inicializada, ela será interceptada.

Isso ocorrerá em outros sistemas operacionais, como Linux ou VxWorks?

Depende principalmente da biblioteca de tempo de execução que você usa.

Você pode dar exemplos práticos de como essa inicialização é útil?

Eu listei alguns acima. Os valores geralmente são escolhidos para aumentar as chances de que algo incomum aconteça se você fizer algo com partes inválidas da memória: atrasos longos, desvios, falhas de alinhamento etc. Os gerentes de heap também às vezes usam valores de preenchimento especiais para as lacunas entre alocações. Se esses padrões mudarem, ele sabe que houve uma gravação incorreta (como uma saturação de buffer) em algum lugar.

Lembro-me de ler algo (talvez no Código Completo 2) que é bom inicializar a memória para um padrão conhecido ao alocá-lo, e certos padrões acionarão interrupções no Win32, o que resultará em exceções exibidas no depurador.

Quão portátil é isso?

Escrever código sólido (e talvez código completo ) fala sobre coisas a considerar ao escolher padrões de preenchimento. Eu mencionei alguns deles aqui, e o artigo da Wikipedia sobre Magic Number (programação) também os resume. Alguns dos truques dependem das especificidades do processador que você está usando (por exemplo, se ele requer leituras e gravações alinhadas e quais valores são mapeados para instruções que serão bloqueadas). Outros truques, como usar valores grandes e valores incomuns que se destacam em um despejo de memória, são mais portáteis.

Este artigo descreve padrões incomuns de bits de memória e várias técnicas que você pode usar se encontrar esses valores.

A razão óbvia para o "porquê" é que suponha que você tenha uma classe como esta:

class Foo
{
public:
    void SomeFunction()
    {
        cout << _obj->value << endl;
    }

private:
    SomeObject *_obj;
}

E então você instancia um a Foo e chama SomeFunction, isso causará uma violação de acesso tentando ler0xCDCDCDCD . Isso significa que você esqueceu de inicializar alguma coisa. Essa é a "parte do porquê". Caso contrário, o ponteiro pode ter se alinhado com alguma outra memória, e seria mais difícil depurar. É só informar o motivo pelo qual você recebe uma violação de acesso. Observe que este caso foi bastante simples, mas em uma classe maior é fácil cometer esse erro.

AFAIK, isso só funciona no compilador do Visual Studio quando no modo de depuração (em vez de liberar)

É fácil ver que a memória mudou de seu valor inicial inicial, geralmente durante a depuração, mas às vezes também para o código de lançamento, já que você pode anexar depuradores ao processo enquanto ele estiver em execução.

Também não é apenas memória; muitos depuradores definirão o conteúdo do registro como um valor sentinela quando o processo for iniciado (algumas versões do AIX definirão os registradores nos 0xdeadbeefquais é levemente engraçado).

O compilador IBM XLC possui uma opção "initauto" que atribuirá às variáveis ​​automáticas um valor que você especificar. Eu usei o seguinte para minhas compilações de depuração:

-Wc,'initauto(deadbeef,word)'

Se eu olhasse para o armazenamento de uma variável não inicializada, ela seria definida como 0xdeadbeef