Monday, January 25, 2016

Leakage: 0%

Un script pour décoder les traces d'allocation de mémoire combinées à un mécanisme qui remplace malloc/free par une progression linéaire dans l'espace-mémoire et j'ai pu éliminer la totalité des fuites de mémoire dans le parsing des scripts.

Deuxième étape, une inspection systématique des listes d'animations maintenues par l'Engine lui-même histoire de s'assurer qu'il ne reste aucune référence à un objet libéré (c'est désormais facile, puisque chaque objet libéré se voit écrasé par des 0xfefefefe et que sa mémoire n'est pas ré-attribuée lors du test). Me voici armé pour tester les enchaînement de niveaux, mais jusqu'à un certain point seulement: au bout de quelques itérations, la mémoire disponible pour le test aura été complètement utilisée. Allez, je devrais pouvoir passer aux chargements-suite-à-une-fin-de-niveaux dans le courant de la semaine, et étudier les "script reset" expérimentaux supposés accélérer les chargements de niveaux.

I reached stable parsing, where no trailing objects exist when the GameScript is destroyed. The next test I implemented pointed out an object that was "recycled" but that was still referenced by the Engine's global state. So I am now ready to investigate what happens during levels transitions, both regular and "just reload" experiments. More testing to follow.

2 comments:

  1. nominé aux Vincent's Awards

    ReplyDelete
  2. Anonymous12:08 pm

    Elsewhere in the world:

    GoogleTest will decide that the test FAILed also when it leaks some memory. Especially, we need to ensure that xxxEnvironment::SetUp will configure the Logger class, or it will auto-create some data structure at first use, that will not be reclaimed during test operations, and will declare the test to fail.

    This can be diagnosed using --gtest_filter=$TESTGROUP.$TESTNAME to select one precise test to run and --gtest_repeat=2: the second instance will run correctly while the first instance has failed.

    ReplyDelete

this is the right place for quickstuff