Saturday, May 02, 2015

attach/deleteme explain the double-free issue ?

There are a number of things that looks odd in the current animation management code. Why do we try to unregister a new animation every time we're done testing a special block ? How comes Engine::delanim() is invoked both at GameObject destructor and Animator destructor.


But that wasn't enough to fix the NastyBug I had, that jammed the game as you approached the end of level 1. At that point, I knew that some object -- the power-up at the end of the level -- was restored with a invalid state and animation. I mean, that wasn't even a true state. Parts of it made no sense, while other parts were perfectly sound. I wrote a safetycheck functions that confirm some memory area can be a valid GobState or GobArea, using virtual table addresses as a signature, then scanned every states when the level is ready.

But quite mysteriously, although all the states were valid, the powerup was still waking up with invalid state! In fact, I had *two* of them -- and that explains why the bug did not occurred when you'd beat the level at once -- that had the same identifier "33". One, listed from GameScript's static list of objects, and one that triggered the bug. You can guess what happened from there: the power-up actually survived the level reboot, but because I re-parse all the game logic when the level is rebooted, all the state machine that phoenix-object was referring to had gone, swallowed in the bowels of the memory manager, recycled into other parts -- which precisely depending on the number of inkdrops and other dynamic objects alive when the level is terminated.

I feel better now. It will take some time to come back to a list of things that need some polish, but at least, I can envision a release of School Rush soon enough.


Je pense avoir enfin mis le doigt sur l'horreur qui provoquait l'arrêt complet de Bilou: School Rush dès qu'un jeune joueur s'approchait de la fin du niveau 1. En fait, le power-up ajouté en fin de niveau était en mesure de survivre à la destruction du reste du moteur de jeu lorsque le joueur échoue. Une particularité liée au fait qu'il s'agissait d'un objet statique, mais qui n'était ni HERO ni EVIL. Résultat, dès sa ré-activation dans la "réincarnation" du niveau, il était toujours là, mais son environnement -- animations, machine d'état, etc. avait été réaffecté à un autre usage. Résultats: comportement incohérent du moteur de jeu, voire accès mémoire invalides et écran rouge "guru meditation" qui me pourrissait la vie depuis les premiers essais du "big punch"...

Sauf qu'il y a encore quelque-chose ailleurs ToT.

No comments:

Post a Comment

this is the right place for quickstuff