Then there is one thing you need to do in code to have Valgrind messages actually means something in some cases: I will take your example: ==7300== To see them, rerun with: –leak-check=full –show-reachable=yes At shutdown, you should call a method that clears all the memory you allocated. If you still find reachable block after that, it means you may forget to clear some list you should actually clear while still in game. It still won't prove that you free all the objects you should free while in game, but it shoudl give you a good idea where they are if you put some counters.
Also it is mostly useless to fix the errors in random order. As soon as you have write/read errors, they can triggers many problems everywhere else even if it looks unrelated. Better fix them one at a time, first occurence first.
>(56 direct, 24 indirect) bytes in 7 blocks are definitely lost in loss record 7 of 9 This is a memory leak. Not the worse problem in itself. Usually easy to fix, if you have defined long enough call stack, it will tell you where the memory was allocated, and then you just need to check where the link is broken to free it there.
Heh. Debugging with GDB is a rather specific thing. There are steps you can take to dig deeper and gather more information on your problem with GDB that simply aren't possible any other way.
You are stepping into the (out-of-)bounds of memory management. There are so many reasons why a tutorial for something like this doesn't exist beyond 'valgrind –leak-check=full' there's not much more advice you can get beyond "good luck.". I am not familiar with TBAMUD. Not even going to pretend to be. However, if you have any sort of memory management, you're dealing with another problem. The only "common" and easily fixed problem you're going to find with valgrind will be uninitialized variables. The rest of it is going to either be stock bugs or memory glitches introduced by the user later. These can vary from over running memory bounds (undefined behaviour) to improper use of the fpReserver (a common diku/merc var) variable (also UB). All you can really do is queue off on the file name/numbers an hope for the best…. that, or you're Tyche and read machine code.