Est-ce que l'adresse 0000000C est une adresse spéciale?

Parfois, lorsque vous programmez, les choses se cassent. Vous avez commis une erreur et votre programme essaie de lire à partir d'une mauvaise adresse.

Une chose qui me frappe souvent est que ces exceptions sont:

Access violation at address 012D37BC in module 'myprog.exe'. Read of address 0000000C.

Maintenant, je vois beaucoup de journaux d'erreurs et ce qui me frappe est le: 0000000C. Est-ce une adresse "spéciale"? Je vois d'autres violations d'accès avec de mauvaises lectures mais les adresses semblent juste aléatoires, mais celle-ci revient souvent dans des situations totalement différentes.

00000000est une adresse spéciale (le pointeur nul). 0000000Cest exactement ce que vous obtenez lorsque vous ajoutez un décalage de 12 au pointeur nul, probablement parce que quelqu'un a essayé d'obtenir le zmembre d'une structure comme celle ci-dessous par le biais d'un pointeur qui était en réalité nul.

struct Foo {
    int w, x, y; // or anything else that takes 12 bytes including padding
    // such as: uint64_t w; char x;
    // or: void *w; char padding[8];
    // all assuming an ordinary 32 bit x86 system
    int z;
}

Sous Windows, il est interdit de déréférencer la totalité de la première et de la dernière page , c'est-à-dire le premier ou le dernier 64 Ko de la mémoire de processus (les plages 0x00000000vers 0x0000ffffet 0xffff0000vers 0xffffffffdans une application 32 bits).

Cela consiste à intercepter le comportement non défini de déréférencement d'un pointeur ou d'un index null dans un tableau null. La taille de la page étant de 64 Ko, Windows doit donc empêcher toute plage valide de la première ou de la dernière page.

Cela ne protège pas contre les pointeurs non initialisés qui pourraient avoir n'importe quelle valeur (y compris les adresses valides).

Quant à savoir pourquoi 0x0Csemble plus commun que 0x08(est-ce vraiment? Je ne sais pas; et dans quels types d’applications?), Cela pourrait avoir à voir avec les pointeurs de table de méthodes virtuelles. C'est vraiment plus un commentaire (devinette massive :), mais c'est un peu plus grand, alors allez-y ... Si vous avez une classe avec des méthodes virtuelles, ses propres champs vont être déplacés 0x04. Par exemple, une classe qui hérite d'une autre classe virtuelle peut avoir une structure de mémoire comme celle-ci:

0x00 - VMT pointer for parent
0x04 - Field 1 in parent
0x08 - VMT pointer for child
0x0C - Field 1 in child

Est-ce un scénario commun, ou même proche? Je ne suis pas sûr. Cependant, notez que dans une application 64 bits, cela pourrait être déplacé de manière encore plus intéressante vers la 0x0Cvaleur:

0x00 - VMT parent
0x08 - Field 1 parent
0x0C - VMT child
0x14 - Field 2 child

Il y a donc beaucoup de cas où les applications peuvent avoir un chevauchement important des décalages null-pointeur. Il peut s'agir du premier champ d'une classe enfant ou de son pointeur de table de méthode virtuelle - nécessaire chaque fois que vous appelez une méthode virtuelle sur une instance. Ainsi, si vous appelez une méthode virtuelle sur un nullpointeur, vous obtiendrez une violation d'accès sur sa VMT offset. La prévalence de cette valeur particulière pourrait alors avoir quelque chose à voir avec une API commune fournissant une classe ayant un modèle d'héritage similaire, ou plus vraisemblablement, une interface particulière (tout à fait possible pour certaines classes d'applications, telles que les jeux DirectX). Il serait peut-être possible de suivre une cause commune simple comme celle-ci, mais j'ai tendance à me débarrasser des applications qui effectuent une déréférencement nulle assez rapidement, alors ...