Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUDs
➜ General
➜ Valgrind and memory
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Greven
Canada (835 posts) Bio
|
| Date
| Tue 07 Oct 2003 07:23 AM (UTC) |
| Message
| | 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. |
Nobody ever expects the spanish inquisition!
darkwarriors.net:4848
http://darkwarriors.net | | Top |
|
| Posted by
| Samson
USA (683 posts) Bio
|
| Date
| Reply #1 on Tue 07 Oct 2003 07:30 PM (UTC) |
| Message
| 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. | | Top |
|
| Posted by
| halkeye
Canada (28 posts) Bio
|
| Date
| Reply #2 on Fri 27 Feb 2004 12:39 AM (UTC) |
| Message
| 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) |
Gavin
Dark Warriors - Coder
http://darkwars.wolfpaw.net
telnet://darkwars.wolfpaw.net:4848 | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
14,180 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top