This is taken in part from:
valgrind.org/
Some more info collected from: Arendjr, Vatiken, Ripley and Mudbytes.net
1. Introduction
Valgrind is a memory debugging tool. It can help detect memory-related errors that are common and can lead to crashes or other unpredictable behaviour. You can check if it is installed by typing on your command prompt: valgrind --help
2. Running Valgrind
Do a clean compile on your program. Then use the command line from your MUD's directory:
valgrind --log-file="filename" --leak-check=yes bin/circle -q <port>
3. Simplified Interpreation of Output
I suggest leaving Valgrind running overnight, and using various commands - including spamming new commands you've made, etc.
Then "shutdown die" your MUD. You will see something similar to this output at the very bottom:
==7300== HEAP SUMMARY:
==7300== in use at exit: 826 bytes in 31 blocks
==7300== total heap usage: 309,395 allocs, 309,364 frees, 38,722,578 bytes allocated
==7300==
==7300== 16 (8 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 9
==7300== at 0x4004EC2: calloc (vg_replace_malloc.c:418)
==7300== by 0x813554E: remember (mobact.c:666)
==7300== by 0x8102D51: hit (fight.c:1968)
==7300== by 0x81033ED: perform_attacks (fight.c:2130)
==7300== by 0x8103B09: perform_violence (fight.c:2422)
==7300== by 0x80C9E09: heartbeat (comm.c:1080)
==7300== by 0x80CD2C7: game_loop (comm.c:947)
==7300== by 0x80CEE86: main (comm.c:540)
==7300==
==7300== 80 (56 direct, 24 indirect) bytes in 7 blocks are definitely lost in loss record 7 of 9
==7300== at 0x4004EC2: calloc (vg_replace_malloc.c:418)
==7300== by 0x813554E: remember (mobact.c:666)
==7300== by 0x8102D51: hit (fight.c:1968)
==7300== by 0x806F913: event_whirlwind (act.offensive.c:1205)
==7300== by 0x80E0B39: event_process (dg_event.c:126)
==7300== by 0x80C9810: heartbeat (comm.c:1060)
==7300== by 0x80CD2C7: game_loop (comm.c:947)
==7300== by 0x80CEE86: main (comm.c:540)
==7300==
==7300== LEAK SUMMARY:
==7300== definitely lost: 64 bytes in 8 blocks
==7300== indirectly lost: 32 bytes in 4 blocks
==7300== possibly lost: 0 bytes in 0 blocks
==7300== still reachable: 730 bytes in 19 blocks
==7300== suppressed: 0 bytes in 0 blocks
==7300== Reachable blocks (those to which a pointer was found) are not shown.
==7300== To see them, rerun with: --leak-check=full --show-reachable=yes
Understanding Common Errors:
==12345== Invalid read/write of size X
This typically means your application is reading or writing memory from/to a location that is not allocated to it. Typical causes are trying to access memory through a pointer that has already been freed, accessing through a pointer that has never been initialized, or a buffer overflow.
==12345== Conditional jump or move depends on uninitialised value(s)
This is a typical message that you'll see when you're using the value of some variable, but the variable has never been initialized.
==12345== Invalid free()
This you'll see if you're trying to free the same memory twice, or if you're trying to free memory that wasn't allocated to you in the first place (probably trying to free an uninitialized pointer).
==12345== XX bytes in X blocks are definitely lost in loss record X of X
This is the typical message you will see when a memory leak occurs. Of course the typical way to introduce memory leaks is by allocating memory but overwriting all the pointers to it.
4. Conclusion
Valgrind isn't perfect, although its suggested that it is 99% accurate on its output.
