Tuesday, May 05, 2015

reverse emulator bug ?

Je connaissais le bug d'émulation. Vous savez, ce genre de bug qui ne se produit jamais quand vous testez sur émulateur et qui crashe lamentablement le programme dès qu'il tourne sur une vraie plate-forme (généralement parce qu'elle a de la vraie mémoire).

Why? I can explain easily a bug that happens only on bare metal, but not in an emulator, but this time, it's the opposite. I spent 3 evenings trying to figure out why the emulator crashed before I could explore any issue with DDD. However, on the Real Thing, I can play the game without any issue... 

If I find a way to re-build that emulator from its source, it could be interesting to implement a ring of last N jumps/calls so that we can actually track the reason of such crash. But do I still have the source+compiler combination do to so ?

Là, il semblerait que je viens de passer 3 soirées à tenter de comprendre l'inverse: un bug qui ne se produit que sur l'émulateur. Mais qui crashe l'émulateur, pas le programme émulé, sans espoir de placer des breakpoints ni rien de ce genre. J'avais fini par m'imaginer qu'un vrai "guru meditation screen" serait plus instructif que ce rapport de crash généré par desmume. Et euh ... rien. Pas de bug. Je fait les 4 niveaux deux fois, avec des morts ici et là. Sans que ça ne s'arrête. Au moins, le nouveau système de gestion de mémoire (merci, PAdM) m'a sorti d'un mauvais pas.

1 comment:

PypeBros said...

dans l'industrie JV, ce type d'allocateur (le "tank" de PaDM) est connu sous le nom d'arena allocator