J'essaie d'expliquer les erreurs de segmentation à quelqu'un, et je pensais au kill-screen de niveau 256 dans Pacman, à la manière dont il est déclenché par un dépassement d'entier et à la similitude de son comportement avec "l'état inconnu" souvent décrit dans une segmentation. faute.
Je tiens à dire que c’est un bon exemple de ce que j’appelle une "erreur de segmentation non gérée", mais je préférerais obtenir un deuxième avis avant de propager de fausses informations.
J'ai essayé de le rechercher, mais tout ce que j'obtiens, ce sont des documents sur le bogue lui-même, ainsi que la collaboration entre Hipster Whale et Namco.
Alors, considéreriez-vous le comportement au niveau 256 de Pacman comme un exemple de violation de segmentation non gérée?
Réponses:
Définitivement pas.
L'accès à une adresse mémoire que vous n'avez pas allouée est toujours une erreur de programmation. Et agir sur les informations que vous en retirez produit un comportement indéfini, c'est beaucoup. Je ne sais pas du tout à quelle plate-forme le Pac-man original a été écrit, mais je suis presque sûr qu'il a eu ce comportement, comme n'importe quelle autre machine von Neumann.
Cependant, "faute de segmentation" est un terme technique désignant une condition beaucoup plus spécifique. Cela se produit lorsque l'ordinateur détecte automatiquement que cela se produit et met fin au processus plutôt que de laisser un comportement indéfini se produire. Cela nécessite un modèle de mémoire spécifique (segmenté) avec un étiquetage de propriété sophistiqué. Je ne pense pas que les jeux d'arcade de 1980 aient eu cela, et en fait le comportement du jeu suggère que l'erreur n'a pas été détectée, et le comportement indéfini s'est produit.
la source
Il semble que vous confondiez "comportement indéfini" et "erreur de segmentation".
Une erreur de segmentation non gérée n'existe pas. Une erreur de segmentation est la gestion des erreurs, par définition.
Si aucun système d'exploitation n'a détecté le mauvais accès à la mémoire et mis fin au processus pour des raisons de sécurité, vous ne présentez pas d'erreur de segmentation.
Si quelque chose, alors, c'est un assez bon exemple de la façon dont UB ne résulte pas toujours en une erreur de segmentation.
la source
Aucun de ces termes n'est approprié pour un bogue dans un jeu d'arcade programmé en langage assembleur et fonctionnant sans le matériel de protection de la mémoire ou le système d'exploitation.
Le "comportement indéfini" est un terme technique en C et dans les langages apparentés, inventé par le comité des normes C en 1989. Le code a un comportement indéfini lorsque la spécification de langage ne définit pas ce qu'il va faire. Le langage d'assemblage Z80 n'existe pas: l'effet de chaque opcode avec toutes les entrées possibles est bien défini. La signification anglaise classique de "comportement indéfini" peut être lue pour s'appliquer - l'écran de suppression est un comportement qui n'a pas été défini par les auteurs du jeu - mais je ne l'utiliserais pas dans ce contexte car il est trop probable qu'il donne le mauvais impression.
"Erreur de segmentation" est un terme technique de POSIX, dérivé du jargon de la programmation de système PDP. Les erreurs de segmentation se produisent lorsqu'un programme tente d'accéder à une adresse de mémoire qui n'est pas "mappée" sur quoi que ce soit: le matériel et le système d'exploitation le détectent et arrêtent le programme défectueux, d'une manière soigneusement définie qui permet au programme de récupérer . Quelque chose commecela aurait pu être le résultat d'un bogue dans le programme de jeu Pac-Man, car la carte de circuit imprimé Pac-Man n'occupe qu'un peu moins de la moitié de l'espace d'adressage de 64 ko de la Z80 avec ROM, RAM et périphériques, mais je n'ai ' t été capable de savoir ce que le matériel réel ferait si le logiciel tentait d’accéder à une mémoire non mappée. Quoi qu’il en soit, il serait inapproprié de le qualifier de "défaut de segmentation", car le "système d’exploitation" de Pac-Man (dans la mesure où il en possède même un) n’est pas une implémentation de Unix et, là encore, donnerait la mauvaise impression.
Le bogue de niveau 256, quant à lui, n’accède pas à la mémoire non mappée, il est donc inutile.
Il est exact de dire que le jeu a un bogue qui se manifeste en passant au niveau 256. Il est également exact de dire que la cause première du bogue est un débordement d’entier et que ses conséquences sont une corruption de la mémoire (ou, de manière équivalente, des violations). de mémoire et type de sécurité ). Ce sont tous des termes CS à usage général définis sans référence à un langage ou à un environnement de système d'exploitation particulier.
Il est également exact d'observer que les effets du bogue ressemblent aux effets, dans un environnement moderne, de bogues de corruption de mémoire qui ne provoquent pas d' erreurs de segmentation. Si vous lisez l'un des écrits sur l'exploit de Project Zero , vous verrez une similarité remarquable avec l' analyse de Don Hodges sur l'écran de suppression de Pac-Man .
Notez qu'un émulateur qui ne reproduit pas fidèlement l'écran de neutralisation lorsqu'il est alimenté par les ROM Pac-Man n'émule pas correctement le matériel de jeu.
la source
Le bogue de niveau 256 dans Pac Man se traduit par la lecture par le programme de données dépassant la fin de la table voulue, mais constituant toujours une mémoire lisible , et écrivant dans des parties de l'écran dépassant celles que le programme a l'intention d'écrire, mais toujours bien dans les zones de l'écran que le programme est autorisé à écrire . Aucune autre zone de mémoire n'est affectée.
La raison pour laquelle le bogue rend le jeu injouable est que la machine détermine le moment où un joueur mange des points en examinant ce qui est à l'écran et décide qu'un niveau est terminé lorsque le joueur a mangé 244 points. En écrasant une partie de l'écran, le bogue empêche le joueur de manger 244 points. par conséquent, le jeu ne créditera jamais le joueur d’avoir terminé le niveau et ne rechargera pas l’écran de points.
la source
Comme dit précédemment non, ce n'est pas une faute distincte. J'ajouterai pourquoi le problème survient: c'est un débordement .
Les numéros de niveau sont stockés sur un octet, la plage est donc comprise entre 0 et 255. Chaque fois que vous terminez un niveau, le compteur est incrémenté. Au niveau 256, le compteur est en fait 0 à cause du débordement.
Cependant, le jeu tente d'afficher des fruits en bas du niveau. Le nombre / type de fruits dépend du niveau. La formule affiche un fruit par niveau fini en dessous du niveau 8. Selon le compteur, vous êtes au niveau 0 donc en dessous de 8. Le test est alors valide et vous devez imprimer 255 fruits (l'ancienne valeur du niveau). Ce qui est impossible et donne cet écran en panne.
la source