I'm trying to use valgrind, but I'm kinda uncertain about it. From what I understand, you would boot your mud through it in a similiar manner as doing it through gdb. From there, you let it run, and it can tell you if you didn't free something, or if you've got a memory leak somewhere. Now, ignoring that fact that I can't get it to compile properly, does anyone know of a good MAN for it, or a help website, or can anyone offer some advice? I've had virtually no experience with memory management, and I'm sure that I've got leaks all over my code.
Valgrind and memory
Posted by Greven on Tue 07 Oct 2003 07:23 AM — 3 posts, 14,881 views.
valgrind -v --leak-check=yes --show-reachable=yes --gdb-attach=yes ../src/afkmud 9500
I stick that command inside a file called grind in the area directory. Whenever I need to check for leaks or other memory problems, I shut the mud down normally, then switch to the area dir and invoke that command. You'll need to make sure the grind command has execute permission. You'll see a bunch of stuff about it, and your usual log spam. Then as long as it encounters no issues at startup, your mud will be running inside it for awhile.
If it encounters a problem, it will offer to let you attach to GDB. Usually this is a good idea, but there are exceptions. Such as with the IMC2 client startup. It will complain about overlapping on an imcstrncpy call twice, but after that it runs fine. But if you see something like "invalid read of size 2" or whatever, then you'd want to attach because otherwise your mud is about to crash.
If you encounter no problems, and want to find leaks after running for a few hours ( or ideally days ), the just shut down the mud normally. You'll get a big long pile of output of things that are potential issues. You'll only be concerned with what it says are definitely lost. Still reachable is ok since the mud would still be able to use them.
As for a MAN page, I doubt it has one. Best bet would be to read up at the website you got it from.
I stick that command inside a file called grind in the area directory. Whenever I need to check for leaks or other memory problems, I shut the mud down normally, then switch to the area dir and invoke that command. You'll need to make sure the grind command has execute permission. You'll see a bunch of stuff about it, and your usual log spam. Then as long as it encounters no issues at startup, your mud will be running inside it for awhile.
If it encounters a problem, it will offer to let you attach to GDB. Usually this is a good idea, but there are exceptions. Such as with the IMC2 client startup. It will complain about overlapping on an imcstrncpy call twice, but after that it runs fine. But if you see something like "invalid read of size 2" or whatever, then you'd want to attach because otherwise your mud is about to crash.
If you encounter no problems, and want to find leaks after running for a few hours ( or ideally days ), the just shut down the mud normally. You'll get a big long pile of output of things that are potential issues. You'll only be concerned with what it says are definitely lost. Still reachable is ok since the mud would still be able to use them.
As for a MAN page, I doubt it has one. Best bet would be to read up at the website you got it from.
I really don't know how to real this information.
At one point i belived it was the debian system libraries, but still. How are you supposed to figure out what that kind of information means?
==13756== Reading suppressions file: /usr/lib/valgrind/default.supp
==13756== Estimated CPU clock rate is 1296 MHz
==13756==
==13756== Invalid read of size 1
==13756== at 0x400118C4: (within /lib/ld-2.3.2.so)
==13756== by 0x400062B3: _dl_map_object (in /lib/ld-2.3.2.so)
==13756== by 0x403AC869: (within /lib/libc-2.3.2.so)
==13756== by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==13756== Address 0xFFFFE210 is not stack'd, malloc'd or free'd
==13756==
==13756== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- ==13756==
==13756== Invalid read of size 1
==13756== at 0x400118C4: (within /lib/ld-2.3.2.so)
==13756== by 0x40006A46: _dl_map_object (in /lib/ld-2.3.2.so)
==13756== by 0x403AC869: (within /lib/libc-2.3.2.so)
==13756== by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==13756== Address 0xFFFFE210 is not stack'd, malloc'd or free'd
==13756==
==13756== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- ==13756== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- ==13756== Reading syms from /lib/libnss_db-2.2.so
==13756== object doesn't have a symbol table
==13756== object doesn't have any debug info
==13756== Reading syms from /lib/libnss_files-2.3.2.so
==13756== object doesn't have a symbol table
==13756== object doesn't have any debug info
==13756== Reading syms from /usr/lib/libdb3.so.3.0.2
==13756== object doesn't have a symbol table
==13756== object doesn't have any debug info
==13756==
==13756== Invalid read of size 1
==13756== at 0x400118C4: (within /lib/ld-2.3.2.so)
==13756== by 0x4000D050: _dl_check_map_versions (in /lib/ld-2.3.2.so)
==13756== by 0x403ACE50: (within /lib/libc-2.3.2.so)
==13756== by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==13756== Address 0xFFFFE210 is not stack'd, malloc'd or free'd
==13756==
==13756== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- ==13756==
==13756== Conditional jump or move depends on uninitialised value(s)
==13756== at 0x40009520: _dl_relocate_object (in /lib/ld-2.3.2.so)
==13756== by 0x403ACE25: (within /lib/libc-2.3.2.so)
==13756== by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==13756== by 0x403AD0A8: _dl_open (in /lib/libc-2.3.2.so)
==13756==
==13756== Conditional jump or move depends on uninitialised value(s)
==13756== at 0x40009575: _dl_relocate_object (in /lib/ld-2.3.2.so)
==13756== by 0x403ACE25: (within /lib/libc-2.3.2.so)
==13756== by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==13756== by 0x403AD0A8: _dl_open (in /lib/libc-2.3.2.so)
These are upon crash/exiting... and even then, i don't quite get what they mean.
==12810== 1176 bytes in 42 blocks are definitely lost in loss record 48 of 88
==12810== at 0x4002FAAD: calloc (vg_replace_malloc.c:201)
==12810== by 0x80DC300: load_repairs(area_data*, _IO_FILE*) (db.c:2121)
==12810== by 0x80E5761: load_area_file(area_data*, char*) (db.c:5787)
==12810== by 0x80D8FD2: boot_db(bool) (db.c:890)
==12810==
==12810==
==12810== 1344 bytes in 42 blocks are definitely lost in loss record 50 of 88
==12810== at 0x4002FAAD: calloc (vg_replace_malloc.c:201)
==12810== by 0x80DC0FA: load_shops(area_data*, _IO_FILE*) (db.c:2081)
==12810== by 0x80E5731: load_area_file(area_data*, char*) (db.c:5786)
==12810== by 0x80D8FD2: boot_db(bool) (db.c:890)
==12810==
==12810==
==12810== 1472 bytes in 2 blocks are definitely lost in loss record 53 of 88
==12810== at 0x4002FAAD: calloc (vg_replace_malloc.c:201)
==12810== by 0x81356F9: load_char_obj(descriptor_data*, char*, bool, bool) (save.c:914)
==12810== by 0x80CCB1E: nanny(descriptor_data*, char*) (comm.c:2322)
==12810== by 0x80C9025: game_loop() (comm.c:752)
At one point i belived it was the debian system libraries, but still. How are you supposed to figure out what that kind of information means?
==13756== Reading suppressions file: /usr/lib/valgrind/default.supp
==13756== Estimated CPU clock rate is 1296 MHz
==13756==
==13756== Invalid read of size 1
==13756== at 0x400118C4: (within /lib/ld-2.3.2.so)
==13756== by 0x400062B3: _dl_map_object (in /lib/ld-2.3.2.so)
==13756== by 0x403AC869: (within /lib/libc-2.3.2.so)
==13756== by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==13756== Address 0xFFFFE210 is not stack'd, malloc'd or free'd
==13756==
==13756== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- ==13756==
==13756== Invalid read of size 1
==13756== at 0x400118C4: (within /lib/ld-2.3.2.so)
==13756== by 0x40006A46: _dl_map_object (in /lib/ld-2.3.2.so)
==13756== by 0x403AC869: (within /lib/libc-2.3.2.so)
==13756== by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==13756== Address 0xFFFFE210 is not stack'd, malloc'd or free'd
==13756==
==13756== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- ==13756== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- ==13756== Reading syms from /lib/libnss_db-2.2.so
==13756== object doesn't have a symbol table
==13756== object doesn't have any debug info
==13756== Reading syms from /lib/libnss_files-2.3.2.so
==13756== object doesn't have a symbol table
==13756== object doesn't have any debug info
==13756== Reading syms from /usr/lib/libdb3.so.3.0.2
==13756== object doesn't have a symbol table
==13756== object doesn't have any debug info
==13756==
==13756== Invalid read of size 1
==13756== at 0x400118C4: (within /lib/ld-2.3.2.so)
==13756== by 0x4000D050: _dl_check_map_versions (in /lib/ld-2.3.2.so)
==13756== by 0x403ACE50: (within /lib/libc-2.3.2.so)
==13756== by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==13756== Address 0xFFFFE210 is not stack'd, malloc'd or free'd
==13756==
==13756== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- ==13756==
==13756== Conditional jump or move depends on uninitialised value(s)
==13756== at 0x40009520: _dl_relocate_object (in /lib/ld-2.3.2.so)
==13756== by 0x403ACE25: (within /lib/libc-2.3.2.so)
==13756== by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==13756== by 0x403AD0A8: _dl_open (in /lib/libc-2.3.2.so)
==13756==
==13756== Conditional jump or move depends on uninitialised value(s)
==13756== at 0x40009575: _dl_relocate_object (in /lib/ld-2.3.2.so)
==13756== by 0x403ACE25: (within /lib/libc-2.3.2.so)
==13756== by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==13756== by 0x403AD0A8: _dl_open (in /lib/libc-2.3.2.so)
These are upon crash/exiting... and even then, i don't quite get what they mean.
==12810== 1176 bytes in 42 blocks are definitely lost in loss record 48 of 88
==12810== at 0x4002FAAD: calloc (vg_replace_malloc.c:201)
==12810== by 0x80DC300: load_repairs(area_data*, _IO_FILE*) (db.c:2121)
==12810== by 0x80E5761: load_area_file(area_data*, char*) (db.c:5787)
==12810== by 0x80D8FD2: boot_db(bool) (db.c:890)
==12810==
==12810==
==12810== 1344 bytes in 42 blocks are definitely lost in loss record 50 of 88
==12810== at 0x4002FAAD: calloc (vg_replace_malloc.c:201)
==12810== by 0x80DC0FA: load_shops(area_data*, _IO_FILE*) (db.c:2081)
==12810== by 0x80E5731: load_area_file(area_data*, char*) (db.c:5786)
==12810== by 0x80D8FD2: boot_db(bool) (db.c:890)
==12810==
==12810==
==12810== 1472 bytes in 2 blocks are definitely lost in loss record 53 of 88
==12810== at 0x4002FAAD: calloc (vg_replace_malloc.c:201)
==12810== by 0x81356F9: load_char_obj(descriptor_data*, char*, bool, bool) (save.c:914)
==12810== by 0x80CCB1E: nanny(descriptor_data*, char*) (comm.c:2322)
==12810== by 0x80C9025: game_loop() (comm.c:752)