La mémoire inutilisée est-elle protégée dans l’espace adresse

La mémoire inutilisée dans l’espace d’adressage d’un processus est-elle protégée par une autorisation de lecture, de sorte que l’écriture dans un emplacement pointé par un pointeur unifié, par exemple, provoque toujours une défaillance de la page? Ou est-ce que ce n’est pas le cas, et chaque emplacement de mémoire en dehors du code (quel access est donné en lecture seule), est donné un access en écriture?

Je demande cela parce que mon ami me montrait son code où il n’initialisait pas un pointeur et écrivait dans la mémoire pointée par lui, mais son programme ne plantait toujours pas avec le compilateur mingw gcc pour Windows mais plantait toujours avec Visual C ++ , dans mac ou linux.

Ce que je pense, c’est que le système d’exploitation ne protège pas la mémoire des zones inutilisées et que le plantage est dû au code généré par le mingw, la valeur du pointeur aléatoire pointe vers une zone utilisée cas il indiquait une zone libre. Mais si le système d’exploitation ne protège pas vraiment les zones inutilisées, est-ce que ces bogues, tels que les pointeurs non initialisés, ne seraient pas difficiles à déboguer?

Je suppose que c’est pourquoi il est conseillé de toujours atsortingbuer NULL à un pointeur après avoir appelé delete ou free , de sorte que lorsque quelque chose est accédé avec, cela provoque réellement un crash visible.

Cela dépend de l’implémentation du système d’exploitation. Dans certaines configurations, par exemple, ExecShield protégera la majeure partie de la mémoire qui sort des limites du programme, et il est également fréquent que les premiers octets du segment de données soient protégés (pour signaler un access avec des pointeurs NULL), mais il se peut que le pointeur pointe vers une adresse mémoire valide et arbitraire dans le programme.

Les pointeurs non initialisés ne doivent pas nécessairement pointer vers l’espace d’adressage non utilisé. Ils pourraient très bien être des valeurs qui se rapportent à la mémoire inscriptible. Comme un pointeur sur la stack qui se trouvait être une fonction précédemment exécutée stockant une adresse valide.

Dans un système d’exploitation serveur / de bureau classique (et un certain nombre de systèmes plus petits tels que les téléphones portables), vous disposez d’une mémoire virtuelle. Cela signifie que le système d’exploitation crée une table qui traduit de l’adresse virtuelle utilisée par votre code en une adresse physique qui spécifie la mémoire réelle en cours de traitement. Ce mappage se fait normalement dans les “pages” – par exemple, un bloc de mémoire de 4 Ko à la fois.

Au moins dans le cas habituel, les parties de l’espace d’adressage qui ne sont pas utilisées ne seront pas du tout mappées – c’est-à-dire que le système d’exploitation ne créera pas d’entrée dans la table pour cette partie de l’espace d’adressage. . Notez, cependant, que la mémoire allouée sera (par nécessité) arrondie à un multiple de la taille de la page, de sorte que chaque partie de la mémoire utilisée sera souvent suivie d’une petite quantité qui n’est pas réellement utilisée, mais toujours allouée et “utilisable”. Puisque la protection est également (normalement) effectuée pour chaque page, si le rest de cette page est (disons) en lecture seule, le rest à la fin de la page sera le même.

La protection de la mémoire n’est pas fournie par c / c ++. Vous constaterez peut-être que le pointeur contient un pointeur sur une mémoire valide. Par exemple, une fonction précédente a une variable ptr sur la stack et une autre fonction appelée ultérieurement utilise le même espace de stack pour un pointeur.

Le code suivant affichera “Hello” s’il est compilé et exécuté avec gcc: #include

 char buffer[10]; void function1(void) { char * ptr = buffer; sprintf(buffer, "Hello"); return; } void function2(void) { char * ptr2; printf("%s\n", ptr2); } int main(int argc, char * argv[]) { function1(); function2(); }

Pour les builds de debug, certains compilateurs (je sais que Visual Studio a l’habitude de le faire) initialiseront secrètement toutes les variables comme ptr2 à une mauvaise valeur pour détecter ce type d’erreur.

Normalement, avec C, vous découvrez que la mémoire a été malmenée par le système d’exploitation qui a tué votre programme.

Simplement, je suppose que la réponse est “Non, la mémoire inutilisée dans l’adresse n’est pas protégée de l’espace”. C n’est pas assez sophistiqué pour gérer de telles instances.