Dans Visual Studio C ++, quelles sont les représentations d'allocation de mémoire?

Dans Visual Studio, nous avons tous eu "baadf00d", avons vu "CC" et "CD" lors de l'inspection des variables dans le débogueur en C ++ pendant l'exécution.

D'après ce que je comprends, "CC" est en mode DEBUG uniquement pour indiquer quand une mémoire a été new () ou alloc () et unitilialized. Tandis que "CD" représente la mémoire supprimée ou libérée. Je n'ai vu que "baadf00d" dans la version RELEASE (mais je peux me tromper).

De temps en temps, nous nous retrouvons dans une situation de résolution des fuites de mémoire, des dépassements de mémoire tampon, etc. et ce type d'informations est très pratique.

Quelqu'un serait-il assez aimable pour indiquer quand et dans quels modes la mémoire est définie sur des modèles d'octets reconnaissables à des fins de débogage?

Ce lien contient plus d'informations:

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

* 0xABABABAB: utilisé par HeapAlloc () de Microsoft pour marquer les octets de garde "no man's land" après la mémoire de tas allouée
* 0xABADCAFE: démarrage de cette valeur pour initialiser toute la mémoire libre pour intercepter les pointeurs errants
* 0xBAADF00D: utilisé par LocalAlloc de Microsoft (LMEM_FIXED) pour marquer la mémoire de tas allouée non initialisée
* 0xBADCAB1E: Code d'erreur renvoyé au débogueur Microsoft eVC lorsque la connexion est rompue avec le débogueur
* 0xBEEFCACE: utilisé par Microsoft .NET comme nombre magique dans les fichiers de ressources
* 0xCCCCCCCC: utilisé par la bibliothèque d'exécution de débogage C ++ de Microsoft pour marquer la mémoire de pile non initialisée
* 0xCDCDCDCD: utilisé par la bibliothèque d'exécution de débogage C ++ de Microsoft pour marquer la mémoire de tas non initialisée
* 0xDDDDDDDD: utilisé par le tas de débogage C ++ de Microsoft pour marquer la mémoire de tas libérée
* 0xDEADDEAD: code d'erreur d'arrêt de Microsoft Windows utilisé lorsque l'utilisateur initie manuellement le plantage.
* 0xFDFDFDFD: utilisé par le tas de débogage C ++ de Microsoft pour marquer les octets de garde "no man's land" avant et après la mémoire de tas allouée
* 0xFEEEFEEE: utilisé par HeapFree () de Microsoft pour marquer la mémoire de tas libérée

Il y a en fait pas mal d'informations utiles ajoutées aux allocations de débogage. Ce tableau est plus complet:

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

Adresse Offset Après HeapAlloc () Après malloc () Pendant free () Après HeapFree () Commentaires
0x00320FD8 -40 0x01090009 0x01090009 0x01090009 0x0109005A Informations de tas Win32
0x00320FDC -36 0x01090009 0x00180700 0x01090009 0x00180400 Informations de tas Win32
0x00320FE0 -32 0xBAADF00D 0x00320798 0xDDDDDDDD 0x00320448 Ptr au bloc de tas CRT suivant (alloué plus tôt dans le temps)
0x00320FE4 -28 0xBAADF00D 0x00000000 0xDDDDDDDD 0x00320448 Ptr au bloc de tas CRT précédent (alloué ultérieurement)
0x00320FE8 -24 0xBAADF00D 0x00000000 0xDDDDDDDD 0xFEEEFEEE Nom de fichier de l'appel malloc ()
0x00320FEC -20 0xBAADF00D 0x00000000 0xDDDDDDDD 0xFEEEFEEE Numéro de ligne de l'appel malloc ()
0x00320FF0 -16 0xBAADF00D 0x00000008 0xDDDDDDDD 0xFEEEFEEE Nombre d'octets à malloc ()
0x00320FF4 -12 0xBAADF00D 0x00000001 0xDDDDDDDD 0xFEEEFEEE Type (0 = libéré, 1 = normal, 2 = utilisation CRT, etc.)
0x00320FF8 -8 0xBAADF00D 0x00000031 0xDDDDDDDD 0xFEEEFEEE # de demande, augmente de 0
0x00320FFC -4 0xBAADF00D 0xFDFDFDFD 0xDDDDDDDD 0xFEEEFEEE No mans land
0x00321000 +0 0xBAADF00D 0xCDCDCDCD 0xDDDDDDDD 0xFEEEFEEE Les 8 octets que vous vouliez
0x00321004 +4 0xBAADF00D 0xCDCDCDCD 0xDDDDDDDD 0xFEEEFEEE Les 8 octets que vous vouliez
0x00321008 +8 0xBAADF00D 0xFDFDFDFD 0xDDDDDDDD 0xFEEEFEEE No mans land
0x0032100C +12 0xBAADF00D 0xBAADF00D 0xDDDDDDDD 0xFEEEFEEE Les allocations de tas Win32 sont arrondies à 16 octets
0x00321010 +16 0xABABABAB 0xABABABAB 0xABABABAB 0xFEEEFEEE Win32 comptabilité de tas
0x00321014 +20 0xABABABAB 0xABABABAB 0xABABABAB 0xFEEEFEEE Win32 comptabilité de tas
0x00321018 +24 0x00000010 0x00000010 0x00000010 0xFEEEFEEE Win32 comptabilité de tas
0x0032101C +28 0x00000000 0x00000000 0x00000000 0xFEEEFEEE Win32 comptabilité de tas
0x00321020 +32 0x00090051 0x00090051 0x00090051 0xFEEEFEEE Win32 comptabilité de tas
0x00321024 +36 0xFEEE0400 0xFEEE0400 0xFEEE0400 0xFEEEFEEE Win32 comptabilité de tas
0x00321028 +40 0x00320400 0x00320400 0x00320400 0xFEEEFEEE Win32 comptabilité de tas
0x0032102C +44 0x00320400 0x00320400 0x00320400 0xFEEEFEEE Win32 comptabilité de tas

En ce qui concerne 0xCCet 0xCDen particulier, ce sont des vestiges de l' Intel 8088 / 8086 instruction de processeur ensemble dans les années 1980. 0xCCest un cas particulier de l' opcode interruption logicielle . La version spéciale à un octet permet à un programme de générer une interruption 3 .INT 0xCD0xCC

Bien que les nombres d'interruptions logicielles soient, en principe, arbitraires, INT 3était traditionnellement utilisé pour la fonction d' interruption ou de point d'arrêt du débogueur , une convention qui reste à ce jour. Chaque fois qu'un débogueur est lancé, il installe un gestionnaire d'interruption pour INT 3que lorsque cet opcode est exécuté, le débogueur soit déclenché. En général, il suspend la programmation en cours d'exécution et affiche une invite interactive.

Normalement, l' INTopcode x86 est de deux octets: 0xCDsuivi du numéro d'interruption souhaité de 0 à 255. Maintenant, bien que vous puissiez émettre 0xCD 0x03pour INT 3, Intel a décidé d'ajouter une version spéciale - 0xCCsans octet supplémentaire - car un opcode ne doit être qu'un octet pour fonctionner comme un `` octet de remplissage '' fiable pour la mémoire inutilisée.

Le point ici est de permettre une récupération gracieuse si le processeur saute par erreur dans la mémoire qui ne contient aucune instruction prévue . Les instructions multi-octets ne conviennent pas à cet objectif car un saut erroné pourrait atterrir à n'importe quel décalage d'octet possible où il devrait continuer avec un flux d'instructions correctement formé.

Évidemment, les opcodes à un octet fonctionnent trivialement pour cela, mais il peut aussi y avoir des exceptions bizarres: par exemple, compte tenu de la séquence de remplissage 0xCDCDCDCD(également mentionnée sur cette page), nous pouvons voir qu'elle est assez fiable car peu importe où le pointeur d'instruction atterrit ( sauf peut - être le dernier octet rempli), la CPU peut reprendre l'exécution d'une instruction x86 valide à deux octetsCD CD , dans ce cas pour générer l'interruption logicielle 205 (0xCD).

Plus étrange encore, alors qu'elle CD CC CD CCest 100% interprétable - donnant soit INT 3ou INT 204- la séquence CC CD CC CDest moins fiable, seulement 75% comme indiqué, mais généralement 99,99% lorsqu'elle est répétée comme un remplissage de mémoire de taille int.

_{Macro Assembler Reference , 1987}