Eressea has a pretty simple memory usage pattern. It allocates a bunch of memory during startup, when it loads the current game data file and creates all the regions, factions, units, etc. and the new orders, then stays pretty much flat while it executes the turn, only allocating more memory for messages and auxiliary structures. Then, after the report is written, it exits and the death of the process cleans everything up nicely.

There shouldn’t be a lot of memory leaks in a situation like that, but the code is written with the intention of being able to load and unload data files from the console, for operations like building statistics over time, repairing one file based on data in another, etc. A recent example was “link every familiar in turn X to the same mage they were familiars of in turn X-1″. So while programmatic cleanup is usually not required, it is in a situation like this (after analyzing turn X-1, we should free it before reading turn X to apply the fix).

Another reason for working cleanup code is testing. Unit tests work best when running from clean state, so anything that gets created in one test should be destroyed at the end of it, so it won’t interfere with the next test. My favorite tool for finding leaks like this is valgrind, and recently it was reporting almost 1,000 leaks when run on the full unit test suite. I started a new feature branch to eliminate them, and after a couple of evenings of hard work, I have pared them down to one final leak in the parser that is really hard to track, and a bunch of static variables that are the bane of this code base. As can be expected when doing work like this, I found a number of small errors that were more than just leaks, and added a lot more test coverage, so this should cause overall code stability to go up. The work ended up in one giant pull request, and will be part of the 3.7 version of the code.