Quand et pourquoi un système d'exploitation initialisera-t-il la mémoire à 0xCD, 0xDD, etc. sur malloc / free / new / delete?
Je sais que le système d'exploitation initialise parfois la mémoire avec certains modèles tels que 0xCD et 0xDD. Ce que je veux savoir, c'est quand et pourquoi cela se produit.
Quand
Est-ce spécifique au compilateur utilisé?
Malloc/new et free/delete fonctionnent-ils de la même manière à cet égard?
Est-ce spécifique à la plateforme?
Cela se produira-t-il sur d'autres systèmes d'exploitation, tels que Linux ou VxWorks?
Pourquoi
Ma compréhension est que cela se produit uniquement dans la configuration de débogage Win32, et il est utilisé pour détecter les dépassements de mémoire et pour aider le compilateur à intercepter 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) 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, ce qui entraînera des exceptions dans le débogueur.
Est-ce portable?
Un résumé rapide de ce que les compilateurs de Microsoft utilisent pour divers bits de mémoire non possédée/non initialisée lors de la compilation pour le mode de 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.
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 detect 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 quelques 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 reproducable). 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 l'allocation de std::string ou le tampon passé à fread(). Ces cas utilisent une valeur nommée _SECURECRT_FILL_BUFFER_PATTERN (définie dans crtdefs.h). Je ne sais pas exactement quand il a été introduit, mais il était dans le runtime de débogage par au moins VS 2005 (VC++ 8).
Initialement, la valeur utilisée pour remplir ces tampons était 0xFD - la même valeur utilisée pour 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 valeur 0xFD pourrait ne pas déclencher la détection de ce dépassement car si la taille du tampon était trop grande d'un seul, la valeur de remplissage serait la même que la valeur no man's land utilisée pour initialiser ce canari. Aucun changement dans le no man's land signifie que le dépassement ne serait 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 qu'une variable de pointeur dont l'une de ces valeurs est déréférencée, cela entraînera une violation d'accès, car sur une configuration Windows 32 bits standard, les adresses en mode utilisateur ne seront pas aller plus haut que 0x7fffffff.
Une propriété intéressante sur la valeur de remplissage 0xCCCCCCCC est que dans l'assemblage x86, l'opcode 0xCC est l'opcode int , qui est l'interruption du point d'arrêt logiciel. Donc, si vous essayez d'exécuter du code dans une mémoire non initialisée 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 à différentes valeurs de sorte que dans le débogueur, vous pouvez facilement voir si vous avez débordé dans la mémoire mallocée, un tableau fixe ou un objet non initialisé. Quelqu'un affichera les détails pendant que je les recherche sur Google ...
Ce n'est pas l'OS - 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 trame de pile afin de détecter les débordements de tampon. Un exemple très simple de ce qui est utile est ici (dans la pratique, Visual Studio décèle 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 potentiellement être difficile à trouver. Avec les variables préinitialisées (ou plutôt, la 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 VRAIE - tout sauf 0 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 qui se trouve contenir 0, ce qui signifie que vous pouvez avoir un bug de variable unitialisé qui ne se manifeste qu'en mode Release.
Cela m'a ennuyé, donc j'ai écrit un script pour modifier la valeur de pré-remplissage en modifiant directement le binaire, ce qui m'a permis de trouver des problèmes de variable non initialisés qui n'apparaissent que lorsque la pile contient un zéro. Ce script modifie uniquement le pré-remplissage de la pile; Je n'ai jamais expérimenté le pré-remplissage de tas, bien que cela devrait être possible. 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 sous 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 du malloc et des implémentations gratuites dans la bibliothèque d'exécution du débogage C. Il peut donc s'agir également d'une fonctionnalité du système d'exploitation, mais la plupart du temps, il s'agit simplement de la bibliothèque d'exécution du langage.
Malloc/new et free/delete fonctionnent-ils de la même manière?
La partie de 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 habituellement a les mêmes fonctionnalités.
Est-ce spécifique à la plateforme?
Les détails sont spécifiques à l'exécution. Les valeurs réelles utilisées sont souvent choisies non seulement pour sembler inhabituelles et évidentes lors de la visualisation d'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 pourraient provoquer un défaut d'alignement. De grandes valeurs sont utilisées (par opposition à 0), car elles provoquent des retards surprenants si vous bouclez vers un compteur non initialisé. Sur x86, 0xCC est un int 3 instruction, donc si vous exécutez une mémoire non initialisée, elle sera interceptée.
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 parties de mémoire non valides: longs retards, interruptions, défauts d'alignement, etc. Les gestionnaires de tas utilisent également parfois des valeurs de remplissage spéciales pour les écarts entre les allocations. Si 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, ce qui entraînera des exceptions dans le débogueur.
Est-ce portable?
Écrire du code solide (et peut-être Code complet ) parle de choses à considérer lors du choix des motifs de remplissage. J'en ai mentionné quelques-uns ici, et l'article Wikipedia sur Magic Number (programmation) les résume également. Certaines des astuces dépendent des spécificités du processeur que vous utilisez (comme 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 grandes valeurs et de valeurs inhabituelles qui se démarquent dans un vidage de mémoire, sont plus portables.
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 Foo et appelez SomeFunction, cela donnera une violation d'accès en essayant de lire 0xCDCDCDCD. Cela signifie que vous avez oublié d'initialiser quelque chose. C'est le "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, puisque vous pouvez attacher des débogueurs au processus pendant qu'il est en cours d'exécution.
Ce n'est pas seulement de la mémoire non plus, de nombreux débogueurs définissent le contenu du registre sur une valeur sentinelle lorsque le processus démarre (certaines versions d'AIX définissent certains registres sur 0xdeadbeef qui est légèrement humoristique).
Cet article décrit modèles de bits de mémoire inhabituels et diverses techniques que vous pouvez utiliser si vous rencontrez ces valeurs.
Le compilateur IBM XLC possède une option "initauto" qui affectera 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