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

Question

Dans Visual Studio, nous avons tous eu des "baadf00d", vu des "CC" et des "CD" lors de l'inspection de 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 unitialisée. Alors que "CD" représente la mémoire supprimée ou libérée. Je n'ai vu "baadf00d" que dans la version RELEASE (mais je peux me tromper).

De temps en temps, nous nous trouvons dans une situation où nous devons faire face à des fuites de mémoire, des débordements de mémoire tampon, etc.

Quelqu'un pourrait-il avoir la gentillesse d'indiquer quand et dans quels modes la mémoire est réglée sur des modèles d'octets reconnaissables à des fins de débogage ?

Answer 1

Ce lien contient plus d'informations :

https://en.wikipedia.org/wiki/Magic_number_(programmation)#Debug_values

\* 0xABABABAB : Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory
\* 0xABADCAFE : A startup to this value to initialize all free memory to catch errant pointers
\* 0xBAADF00D : Used by Microsoft's LocalAlloc(LMEM\_FIXED) to mark uninitialised allocated heap memory
\* 0xBADCAB1E : Error Code returned to the Microsoft eVC debugger when connection is severed to the debugger
\* 0xBEEFCACE : Used by Microsoft .NET as a magic number in resource files
\* 0xCCCCCCCC : Used by Microsoft's C++ debugging runtime library to mark uninitialised stack memory
\* 0xCDCDCDCD : Used by Microsoft's C++ debugging runtime library to mark uninitialised heap memory
\* 0xDDDDDDDD : Used by Microsoft's C++ debugging heap to mark freed heap memory
\* 0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually initiates the crash.
\* 0xFDFDFDFD : Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory
\* 0xFEEEFEEE : Used by Microsoft's HeapFree() to mark freed heap memory

Answer 2

Il y a en fait pas mal d'informations utiles ajoutées pour déboguer les allocations. Ce tableau est plus complet :

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

Address  Offset After HeapAlloc() After malloc() During free() After HeapFree() Comments
0x00320FD8  -40    0x01090009    0x01090009     0x01090009    0x0109005A     Win32 heap info
0x00320FDC  -36    0x01090009    0x00180700     0x01090009    0x00180400     Win32 heap info
0x00320FE0  -32    0xBAADF00D    0x00320798     0xDDDDDDDD    0x00320448     Ptr to next CRT heap block (allocated earlier in time)
0x00320FE4  -28    0xBAADF00D    0x00000000     0xDDDDDDDD    0x00320448     Ptr to prev CRT heap block (allocated later in time)
0x00320FE8  -24    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Filename of malloc() call
0x00320FEC  -20    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Line number of malloc() call
0x00320FF0  -16    0xBAADF00D    0x00000008     0xDDDDDDDD    0xFEEEFEEE     Number of bytes to malloc()
0x00320FF4  -12    0xBAADF00D    0x00000001     0xDDDDDDDD    0xFEEEFEEE     Type (0=Freed, 1=Normal, 2=CRT use, etc)
0x00320FF8  -8     0xBAADF00D    0x00000031     0xDDDDDDDD    0xFEEEFEEE     Request #, increases from 0
0x00320FFC  -4     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land
0x00321000  +0     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted
0x00321004  +4     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted
0x00321008  +8     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land
0x0032100C  +12    0xBAADF00D    0xBAADF00D     0xDDDDDDDD    0xFEEEFEEE     Win32 heap allocations are rounded up to 16 bytes
0x00321010  +16    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping
0x00321014  +20    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping
0x00321018  +24    0x00000010    0x00000010     0x00000010    0xFEEEFEEE     Win32 heap bookkeeping
0x0032101C  +28    0x00000000    0x00000000     0x00000000    0xFEEEFEEE     Win32 heap bookkeeping
0x00321020  +32    0x00090051    0x00090051     0x00090051    0xFEEEFEEE     Win32 heap bookkeeping
0x00321024  +36    0xFEEE0400    0xFEEE0400     0xFEEE0400    0xFEEEFEEE     Win32 heap bookkeeping
0x00321028  +40    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping
0x0032102C  +44    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping

Answer 3

Concernant 0xCC y 0xCD en particulier, il s'agit de reliques du Intel 8088 / 8086 le jeu d'instructions du processeur dans les années 1980. 0xCC est un cas particulier de la interruption logicielle opcode INT 0xCD . La version spéciale à un seul octet 0xCC permet à un programme de générer interrompre 3 .

Bien que les numéros d'interruption du logiciel soient, en principe, arbitraires, INT 3 était traditionnellement utilisé pour le arrêt du débogage o point d'arrêt fonction, une convention qui perdure à ce jour. Chaque fois qu'un débogueur est lancé, il installe un gestionnaire d'interruption pour la fonction INT 3 de telle sorte que lorsque cet opcode sera exécuté, le débogueur sera déclenché. En général, il mettra en pause la programmation en cours et affichera une invite interactive.

Normalement, le système x86 INT L'opcode est de deux octets : 0xCD suivi du numéro d'interruption souhaité de 0 à 255. Maintenant, bien que vous puissiez émettre 0xCD 0x03 para 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 comporter qu'un seul octet afin de fonctionner comme un "octet de remplissage" fiable pour la mémoire inutilisée.

L'objectif est de permettre une reprise en douceur. si le processeur saute par erreur dans une mémoire qui ne contient pas les instructions prévues . Les instructions multi-octets ne sont pas adaptées à cet objectif puisqu'un saut erroné pourrait atterrir à n'importe quel décalage d'octet possible où il faudrait continuer avec un flux d'instructions correctement formé.

Évidemment, les opcodes d'un octet fonctionnent trivialement 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 qu'il est assez fiable puisque, peu importe où se trouve le fichier pointeur d'instruction terres (sauf peut-être le dernier octet rempli), le CPU peut reprendre l'exécution d'un programme valide deux octets Instruction x86 CD CD dans ce cas, pour générer l'interruption logicielle 205 (0xCD).

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

_{<em>Référence de l'assembleur de macros </em>, 1987}