20 Jan, 2013, Zusuk wrote in the 1st comment:
Votes: 0
Hey folks:

Zusuk here, I'm working on the LuminariMUD project, which is a sort of merging of CWG/d20 on top of TBA codebase.

I stop by here when I can, but I spend most of my forum time on TBA forums since its more focused on the codebase I'm using.

I'm interested in compiling a Valgrind tutorial in similar fashion to the GDB tutorial we have on the TBA forums:
http://tbamud.com/forum/4-development/6-...

If anyone experienced is interested in helping me compile information on how to debug common error messages for us "not so experienced" coders, that would be awesome.

The start of this post is at:
http://tbamud.com/forum/4-development/13...

Thanks in advance!
20 Jan, 2013, Rarva.Riendf wrote in the 2nd comment:
Votes: 0
You can start with this:
http://cs.ecs.baylor.edu/~donahoo/tools/...

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.
20 Jan, 2013, Davion wrote in the 3rd comment:
Votes: 0
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.
23 Jan, 2013, Zusuk wrote in the 4th comment:
Votes: 0
Thanks a lot for the responses guys :)
0.0/4