Le "bug de niveau 256" dans le jeu de Pacman peut-il être considéré comme une erreur de segmentation non gérée?
J'essaie d'expliquer les défauts de segmentation à quelqu'un, et je pensais au kill-screen de niveau 256 dans Pacman, et comment il est déclenché par un débordement d'entier, et à quel point le comportement est similaire à "l'état inconnu" souvent décrit dans une segmentation faute.
Je tiens à dire que c'est un bon exemple de ce que j'appelle un "défaut de gestion non géré", mais je préfère obtenir un deuxième avis avant de propager potentiellement de la désinformation.
J'ai essayé de le rechercher, mais tout ce que je reçois, ce sont des documents sur le bogue lui-même, ainsi que cette 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?
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 exact. Je n'ai aucune idée de la plate-forme pour laquelle le Pac-man original a été écrit, mais je suis presque sûr qu'il a présenté ce comportement comme n'importe quelle autre machine von Neumann.
Cependant, "défaut de segmentation" est un terme technique pour une condition beaucoup plus spécifique. Cela se produit lorsque l'ordinateur détecte automatiquement que cela s'est produit et termine le processus plutôt que de permettre à un comportement indéfini de se produire. Cela nécessite un modèle de mémoire spécifique (segmenté) avec un marquage de propriété sophistiqué. Je ne pense pas que les jeux d'arcade de 1980 avaient cela, et en fait, le comportement du jeu suggère que l'erreur a été pas détectée, et le comportement indéfini did s'est produit.
Il semble que vous confondiez "comportement indéfini" et "faute de segmentation".
Il n'y a rien de tel qu'une faute de segmentation non gérée. Un défaut de segmentation is gestion des erreurs, par définition.
Si vous n'avez pas de système d'exploitation qui a détecté le mauvais accès à la mémoire et a mis fin au processus pour des raisons de sécurité, vous n'avez pas de défaut de segmentation.
Si quoi que ce soit, alors, c'est un assez bon exemple de la façon dont UB ne pas entraîne toujours un défaut de segmentation.
Aucun de ces termes n'est approprié pour un bogue dans un jeu d'arcade qui a été programmé en langage assembleur et s'exécute sans bénéficier de matériel de protection de la mémoire ou de système d'exploitation.
"Comportement indéfini" est un terme technique en C et langages apparentés, inventé par le comité des normes C en 1989. Le code a un comportement indéfini lorsque la spécification du langage ne définit pas ce qu'il fera. Il n'y a rien de tel dans le langage d'assemblage Z80: l'effet de chaque opcode avec chaque entrée possible est bien défini. Le sens anglais conventionnel de "comportement indéfini" peut être lu pour s'appliquer - l'écran de mise à mort est un comportement non défini par les personnes qui ont écrit le jeu - mais je ne l'utiliserais pas dans ce contexte car il est trop susceptible de donner le mauvais impression.
Le "défaut de segmentation" est un terme de l'art dans POSIX, dérivé finalement du jargon de programmation du système PDP. Des erreurs de segmentation se produisent lorsqu'un programme tente d'accéder à une adresse mémoire qui n'est "mappée" à rien: 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 comme cela aurait pu se produire à la suite d'un bug dans le programme de jeu Pac-Man, car la carte de circuit imprimé Pac-Man ne remplit qu'un peu moins de la moitié de l'espace d'adressage de 64 Ko du Z80 avec ROM, RAM et périphériques, mais je n'ai pas été en mesure de savoir ce que le véritable matériel ferait si le logiciel tentait d'accéder à la mémoire non mappée. Quoi qu'il fasse, cependant, il serait inapproprié de le décrire comme un "défaut de segmentation", car le "système d'exploitation" de Pac-Man (dans la mesure où il ( a un) n'est pas pas une implémentation d'Unix et, encore une fois, cela donnerait une mauvaise impression.
Le bogue de niveau 256, quant à lui, n'accède pas à la mémoire non mappée, il est donc théorique.
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 mémoire (ou , de manière équivalente, violations de la mémoire et de la sécurité des types ). 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 sont similaires aux effets, dans un environnement moderne, des bogues de corruption de mémoire qui ne provoque pas de défauts de segmentation. Si vous lisez l'un des Project Zero exploiter les écritures, vous verrez une similitude remarquable avec Don Hodges analyse de l'écran de tuer Pac-Man .
Notez qu'un émulateur qui ne reproduit pas fidèlement l'écran de suppression lorsqu'il est alimenté par les ROM Pac-Man n'émule pas correctement le matériel du jeu.
Le bogue de niveau 256 dans Pac Man entraîne le programme lecture données qui est au-delà de la fin de la table prévue, mais est stockage toujours lisible, et écrit dans des parties de la écran qui sont au-delà de ceux que le programme a l'intention d'écrire, mais qui sont 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 bug rend le jeu injouable est que la machine détermine quand 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 bug 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 rechargera l'écran avec des points.
Comme dit précédemment non ce n'est pas une faute de segmentation. J'ajouterai pourquoi le problème se produit: c'est un débordement.
Les numéros de niveau sont stockés sur un octet, la plage est donc de 0 à 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 essaie d'afficher des fruits en bas du niveau. Le nombre/type de fruit dépend du niveau. La formule affiche un fruit par niveau fini sous le niveau 8. Selon le compteur, vous êtes au niveau 0 donc sous 8. Le test est alors vrai et vous devez imprimer 255 fruits (l'ancienne valeur de niveau). Ce qui est impossible et donne cet écran glitched.