Dans Visual Studio C ++, quelles sont les représentations d'allocation de mémoire?
Dans Visual Studio, nous avions tous "baadf00d", vu "CC" et "CD" lors de l'inspection de variables dans le débogueur en C++ pendant l'exécution.
D'après ce que j'ai compris, "CC" est en mode DEBUG uniquement pour indiquer le moment où une mémoire a été new () ou alloc () et unitilialized. Alors que "CD" représente la mémoire supprimée ou libérée. J'ai seulement vu "baadf00d" dans la version RELEASE (mais je me trompe peut-être).
De temps en temps, nous rencontrons des problèmes de fuite de mémoire, de débordement de mémoire tampon, etc. Ces informations sont très utiles.
Quelqu'un aurait-il la gentillesse de préciser quand et dans quels modes la mémoire est configurée avec des modèles d'octets reconnaissables à des fins de débogage?
Ce lien a plus d'informations:
http://en.wikipedia.org/wiki/Magic_number_ (programmation)
* 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: un démarrage à cette valeur pour initialiser toute la mémoire libre afin d'attraper les pointeurs erronés * 0xBAADF00D: utilisé par LocalAlloc (LMEM_FIXED) de Microsoft pour marquer la mémoire non allouée allouée * 0xBADCAB1E: Code d'erreur renvoyé au débogueur Microsoft eVC lorsque la connexion est interrompue avec le débogueur * 0xBEE : 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 * 0xCDCDCD: utilisé par la bibliothèque d'exécution de débogage C++ de Microsoft pour marquer mémoire de segment non initialisée * 0xDDDDDDDD: utilisé par le segment de débogage C++ de Microsoft pour marquer la mémoire de segment libérée * 0xDEADDEAD: code d'erreur Microsoft Windows STOP utilisé lorsque l'utilisateur initie manuellement le blocage. * 0xFDFDFDFD: utilisé par le tas de débogage C++ de Microsoft pour marquer "no man's land" octets de garde 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
En fait, de nombreuses informations utiles ont été ajoutées aux allocations de débogage. Ce tableau est plus complet:
http://www.nobugs.org/developer/win32/debug_crt_heap.html#table
Décalage d'adresse après HeapAlloc () après malloc () Pendant free () après HeapFree () Commentaires 0x00320FD8 -40 0x01090009 0x01090009 0x01090009 0x0109005A Win32 informations de tas 0x00320F0930930930930930930930930930930930930930930930930930930929309299 0x00180400 Informations sur le tas Win32 0x00320FE0 -32 0xBAADF00D 0x00320798 0xDDDDDDDD 0x00320448 Ptr vers le bloc de tas de CRT suivant (alloué plus tôt) 0x00320FE4 -28 0xBAADF00D Le numéro de fichier de malloc () est composé de 0xFEEEFEEE Nombre d'octets de malloc () 0x00320FF4 -12 0xBAADF00D 0x00000001 0xDDDDDDDDD 0xFEEEFEEE Type (0 = Libéré, 1 = normal, 2 = utilisation du tube cathodique, etc.) ] DX00321000 Les allocations de tas Win32 sont arrondies à 16 octets . 0x00321010 +16 ] 0x00321018 +24 0x00000010 0x00000010 0x00000010 0xFEEEFEEE livre de tas Win32 gardant 0x0032101C +28 0x00000000 0x00000000 0x00000000 0xFEEEFEEE Win32 comptabilité de tas 0x00321020 +32 0x00090051 0x00090051 0x00090051 0xFEEEFEEE Win32 comptabilité de tas 0x00321020 +32 0x00090051 0x00090051 0x00090051 0xFEEEFEEE Win32 livre. ] 0x00321028 +40 0x00320400 0x00320400 0x00320400 0xFEEEFEEE livre de tas Win32 0x0032102C +44 0x00320400 0x00320400 0x00320400 livre de tas 0xFEEEFEEE Win32
En ce qui concerne 0xCC et 0xCD en particulier, il s’agit de reliques de Intel 8088 / 8086instructions du processeur définies dans les années 1980. 0xCC est un cas particulier de l'opcode d'interruption logiciel INT0xCD. La version spéciale à un octet 0xCC permet à un programme de générer interruption 3.
Bien que les numéros d’interruption logicielle soient, en principe, arbitraires, INT 3 était traditionnellement utilisé pour la fonction du débogueur breakou breakpoint , une convention qui reste à ce jour. Chaque fois qu'un débogueur est lancé, il installe un gestionnaire d'interruption pour INT 3, de sorte que le débogueur sera déclenché lorsque cet opcode sera exécuté. En règle générale, il suspend la programmation en cours et affiche une invite interactive.
Normalement, l'opcode x86 INT est composé de deux octets: 0xCD suivi du numéro d'interruption souhaité, compris entre 0 et 255. Maintenant, bien que vous puissiez émettre 0xCD 0x03 pour INT 3, Intel a décidé d'ajouter une version spéciale --0xCC sans octet supplémentaire - car un code d'opération ne doit en être qu'un. octet afin de fonctionner comme un "octet de remplissage" fiable pour la mémoire inutilisée.
Le but ici est de permettre une récupération en douceur si le processeur saute par erreur dans une mémoire qui ne contient aucune instruction prévue. Les instructions sur plusieurs octets ne conviennent pas à cet objectif puisqu'un saut erroné pourrait atterrir à tout décalage d'octet possible où il devrait continuer avec un flux d'instructions correctement formé.
Bien sûr, les opcodes à un octet fonctionnent de manière triviale pour cela, mais il peut aussi y avoir des exceptions bizarres: par exemple, en considérant la séquence de remplissage 0xCDCDCDCD (également mentionné sur cette page), nous pouvons voir que c'est assez fiable, car aucun Où que le pointeur d'instruction atterrisse (sauf peut-être le dernier octet rempli), la CPU peut reprendre l'exécution d'un valide de deux octets.Instruction x86 CD CD, dans ce cas pour générer une interruption logicielle 205 (0xCD).
Encore plus étrange, alors que CD CC CD CC est interprétable à 100% - soit INT 3 ou INT 204-- la séquence CC CD CC CD est moins fiable, uniquement 75% comme indiqué, mais généralement 99,99% lorsqu’il est répété en tant que remplissage de mémoire au format int.
Référence d'assembleur de macro, 1987