Quand et pourquoi un compilateur initialisera-t-il la mémoire à 0xCD, 0xDD, etc. sur malloc / free / new / delete?

Je sais que le compilateur initialisera parfois la mémoire avec certains modèles tels que 0xCDet 0xDD. Ce que je veux savoir, c'est quand et pourquoi cela se produit.

Quand

Est-ce spécifique au compilateur utilisé?

Faire malloc/newet free/deletetravailler de la même manière à cet égard?

Est-ce spécifique à la plate-forme?

Cela se produira-t-il sur d'autres systèmes d'exploitation, tels que Linuxou VxWorks?

Pourquoi

Je crois comprendre que cela ne se produit que dans la Win32configuration de débogage, et il est utilisé pour détecter les dépassements de mémoire et pour aider le compilateur à détecter les exceptions.

Pouvez-vous donner des exemples pratiques de l'utilité de cette initialisation?

Je me souviens avoir lu quelque chose (peut-être dans Code Complete 2) disant qu'il est bon d'initialiser la mémoire sur un modèle connu lors de l'allocation, et certains modèles déclencheront des interruptions Win32qui entraîneront des exceptions dans le débogueur.

À quel point est-ce portable?

Un résumé rapide de ce que les compilateurs de Microsoft utilisent pour divers bits de mémoire non propriétaire / non initialisée lorsqu'ils sont compilés pour le mode débogage (la prise en charge peut varier selon la version du compilateur):

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(). 

Avertissement: le tableau provient de certaines notes que j'ai traîner - elles peuvent ne pas être correctes à 100% (ou cohérentes).

Beaucoup de ces valeurs sont définies dans 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 */

Il y a aussi quelques fois où le runtime de débogage remplira les tampons (ou des parties de tampons) avec une valeur connue, par exemple, l'espace «mou» dans std::stringl'allocation de ou le tampon passé à fread(). Ces cas utilisent une valeur donnée par le nom _SECURECRT_FILL_BUFFER_PATTERN(défini dans crtdefs.h). Je ne sais pas exactement quand il a été introduit, mais il était dans le runtime de débogage d'au moins VS 2005 (VC ++ 8).

Au départ, la valeur utilisée pour remplir ces tampons était 0xFD- la même valeur que celle utilisée pour le no man's land. Cependant, dans VS 2008 (VC ++ 9), la valeur a été modifiée en 0xFE. Je suppose que c'est parce qu'il pourrait y avoir des situations où l'opération de remplissage s'exécuterait au-delà de la fin du tampon, par exemple, si l'appelant passait dans une taille de tampon trop grande pour fread(). Dans ce cas, la valeur0xFD pourrait ne pas déclencher la détection de ce dépassement car si la taille de la mémoire tampon était trop grande d'un seul, la valeur de remplissage serait la même que la valeur du no man's land utilisée pour initialiser ce canari. Aucun changement dans le no man's land signifie que le dépassement ne sera pas remarqué.

Ainsi, la valeur de remplissage a été modifiée dans VS 2008 afin qu'un tel cas change le canari du no man's land, entraînant la détection du problème par le runtime.

Comme d'autres l'ont noté, l'une des propriétés clés de ces valeurs est que si une variable de pointeur avec l'une de ces valeurs est dé-référencée, cela entraînera une violation d'accès, car sur une configuration Windows standard 32 bits, les adresses en mode utilisateur n'ira pas plus haut que 0x7fffffff.

Une propriété intéressante à propos de la valeur de remplissage 0xCCCCCCCC est que dans l'assemblage x86, l'opcode 0xCC est le opcode int3 , qui est l'interruption du point d'arrêt du logiciel. Donc, si jamais vous essayez d'exécuter du code dans une mémoire non initialisée qui a été remplie avec cette valeur de remplissage, vous atteindrez immédiatement un point d'arrêt et le système d'exploitation vous permettra d'attacher un débogueur (ou de tuer le processus).

Il est spécifique au compilateur et au système d'exploitation, Visual studio définit différents types de mémoire sur des valeurs différentes afin que, dans le débogueur, vous puissiez facilement voir si vous avez dépassé en mémoire mallocée, un tableau fixe ou un objet non initialisé. Quelqu'un affichera les détails pendant que je les googlerai ...

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

Ce n'est pas le système d'exploitation - c'est le compilateur. Vous pouvez également modifier le comportement - voir en bas de cet article.

Microsoft Visual Studio génère (en mode débogage) un binaire qui pré-remplit la mémoire de la pile avec 0xCC. Il insère également un espace entre chaque frame de pile afin de détecter les débordements de tampon. Voici un exemple très simple où cela est utile (en pratique, Visual Studio détecte ce problème et émet un avertissement):

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

Si Visual Studio n'a pas préinitialisé les variables à une valeur connue, ce bogue peut être difficile à trouver. Avec des variables pré-initialisées (ou plutôt, une mémoire de pile pré-initialisée), le problème est reproductible à chaque exécution.

Cependant, il y a un léger problème. La valeur utilisée par Visual Studio est TRUE - tout sauf 0 le serait. Il est en fait très probable que lorsque vous exécutez votre code en mode Release, des variables unitialisées puissent être allouées à un morceau de mémoire de pile contenant 0, ce qui signifie que vous pouvez avoir un bogue de variable unitialisée qui ne se manifeste qu'en mode Release.

Cela m'a ennuyé, j'ai donc écrit un script pour modifier la valeur de pré-remplissage en éditant directement le binaire, me permettant de trouver des problèmes de variables non activées qui n'apparaissent que lorsque la pile contient un zéro. Ce script ne modifie que le pré-remplissage de la pile; Je n'ai jamais expérimenté le pré-remplissage du tas, même si cela devrait être possible. Cela peut impliquer la modification de la DLL d'exécution, peut-être pas.

Est-ce spécifique au compilateur utilisé?

En fait, c'est presque toujours une fonctionnalité de la bibliothèque d'exécution (comme la bibliothèque d'exécution C). Le runtime est généralement fortement corrélé avec le compilateur, mais vous pouvez permuter certaines combinaisons.

Je crois que sur Windows, le tas de débogage (HeapAlloc, etc.) utilise également des modèles de remplissage spéciaux qui sont différents de ceux qui proviennent de malloc et des implémentations gratuites dans la bibliothèque d'exécution de débogage C. Donc, cela peut aussi être une fonctionnalité du système d'exploitation, mais la plupart du temps, ce n'est que la bibliothèque d'exécution du langage.

Est-ce que malloc / new et free / delete fonctionnent de la même manière à cet égard?

La partie gestion de la mémoire de new et delete est généralement implémentée avec malloc et free, donc la mémoire allouée avec new et delete a généralement les mêmes fonctionnalités.

Est-ce spécifique à la plate-forme?

Les détails sont spécifiques à l'exécution. Les valeurs réelles utilisées sont souvent choisies non seulement pour paraître inhabituelles et évidentes lorsque l'on regarde un vidage hexadécimal, mais sont conçues pour avoir certaines propriétés qui peuvent tirer parti des fonctionnalités du processeur. Par exemple, des valeurs impaires sont souvent utilisées, car elles peuvent provoquer un défaut d'alignement. Des valeurs élevées sont utilisées (par opposition à 0), car elles provoquent des retards surprenants si vous bouclez vers un compteur non initialisé. Sur x86, 0xCC est une int 3instruction, donc si vous exécutez une mémoire non initialisée, elle piège.

Cela se produira-t-il sur d'autres systèmes d'exploitation, tels que Linux ou VxWorks?

Cela dépend principalement de la bibliothèque d'exécution que vous utilisez.

Pouvez-vous donner des exemples pratiques de l'utilité de cette initialisation?

J'en ai énuméré ci-dessus. Les valeurs sont généralement choisies pour augmenter les chances que quelque chose d'inhabituel se produise si vous faites quelque chose avec des portions de mémoire invalides: longs délais, interruptions, défauts d'alignement, etc. Les gestionnaires de tas utilisent aussi parfois des valeurs de remplissage spéciales pour les espaces entre les allocations. Si jamais ces modèles changent, il sait qu'il y a eu une mauvaise écriture (comme un dépassement de tampon) quelque part.

Je me souviens avoir lu quelque chose (peut-être dans Code Complete 2) qu'il est bon d'initialiser la mémoire sur un modèle connu lors de son allocation, et certains modèles déclencheront des interruptions dans Win32 qui entraîneront des exceptions dans le débogueur.

À quel point est-ce portable?

L'écriture de code solide (et peut-être de code complet ) traite des éléments à prendre en compte lors du choix des motifs de remplissage. J'en ai mentionné quelques-uns ici, et l'article de Wikipedia sur Magic Number (programmation) les résume également. Certaines des astuces dépendent des spécificités du processeur que vous utilisez (par exemple, s'il nécessite des lectures et des écritures alignées et quelles valeurs correspondent aux instructions qui intercepteront). D'autres astuces, comme l'utilisation de valeurs élevées et de valeurs inhabituelles qui se démarquent dans un vidage de mémoire, sont plus portables.

Cet article décrit des modèles de bits de mémoire inhabituels et diverses techniques que vous pouvez utiliser si vous rencontrez ces valeurs.

La raison évidente du "pourquoi" est que supposons que vous ayez une classe comme celle-ci:

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

private:
    SomeObject *_obj;
}

Et puis vous instanciez un Fooet appelez SomeFunction, cela donnera une violation d'accès en essayant de lire0xCDCDCDCD . Cela signifie que vous avez oublié d'initialiser quelque chose. C'est la partie «pourquoi». Sinon, le pointeur pourrait s'être aligné avec une autre mémoire et il serait plus difficile à déboguer. Il s'agit simplement de vous informer de la raison pour laquelle vous obtenez une violation d'accès. Notez que ce cas était assez simple, mais dans une classe plus grande, il est facile de faire cette erreur.

AFAIK, cela ne fonctionne que sur le compilateur Visual Studio en mode débogage (par opposition à la version)

C'est pour voir facilement que la mémoire a changé par rapport à sa valeur de départ initiale, généralement pendant le débogage, mais parfois aussi pour le code de version, car vous pouvez attacher des débogueurs au processus pendant son exécution.

Ce n'est pas seulement de la mémoire, de nombreux débogueurs définiront le contenu des registres sur une valeur sentinelle au démarrage du processus (certaines versions d'AIX définiront certains registres sur 0xdeadbeeflesquels il est légèrement humoristique).

Le compilateur IBM XLC dispose d'une option "initauto" qui attribuera aux variables automatiques une valeur que vous spécifiez. J'ai utilisé ce qui suit pour mes versions de débogage:

-Wc,'initauto(deadbeef,word)'

Si je regardais le stockage d'une variable non initialisée, elle serait définie sur 0xdeadbeef