Well, it would be creating a new instance of an object or objects (the mob's corpse and any coins it had, possibly dropped body parts), so that could possibly cause it... I forgot to tell you how to attach gdb to a running process earlier after you started using splint, but you can use gdb to set a watchpoint for nAllocPerm and see when it's incrementing, then trace back to see why... to attach to a running process, you can either do it at boot time or while the game is running like so:
At boot time: cd into your area directory and do the following: gdb ../src/rom (or whatever your executable is named) run 7777 (or whatever your port # is) During run time: Cd into your src directory and do the following: ps -ux (get the PID of the mud's process, we'll use 12345 for this example) gdb ./rom 12345 (or whatever your executable is named) continue when you attach to the running process it will pause the mud, so you need to continue to set it in motion again, and you'll probably want to set your watchpoint(s) before doing so... you can hit ^C while the game is running, and it'll pause the game and give you a prompt to work with in gdb... I wrote a little faq/tutorial for some of the more common gdb usage on frostmud.com a while back, it's pretty decent with lots of examples... I was going to post the url straight to it in this message, but when I went to get it, I haven't logged in for so long my forum acct got wiped, and I'm too lazy to recreate it right now :D so if you want to go to frostmud.com and click on the forum link, register, and go into the Help section, there should be one from Velveeta about a gdb tutorial (you may have to set the date to show up a bit, some of those php boards only show from the last 30 days by default, and this was made sometime last year)... hope it helps... Richard Lindsey. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Valnir Sent: Wednesday, April 06, 2005 10:01 AM To: [email protected] Subject: Re: Memory issues. Ok.. maybe this will help to point where a lot of memory leaks are. I opened up a duplicate copy of my mud on our dev port and logged in. While running "top" at the shell, to watch the mem usage of the process, I went and killed one of our high level mobs, using mortal weapons and spells. Mem Usage Before Fight: 10460k Mem Usage After Fight: 10580k Now mind you, I am the ONLY one logged in there. Any thoughts? - Valnir ----- Original Message ----- From: "Michael Barton" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, April 06, 2005 10:19 AM Subject: Re: Memory issues. >> #3 0x486d176d in sprintf () from /lib/libc.so.6 >> #4 0x0807127e in do_mstat (ch=0x4956017c, argument=0x487afd24 "8,\023") >> at >> act_wiz.c:2143 > > The problem's probably with a call to sprintf on that line in act_wiz. > Look at the buffer size and how much is being copied into it, make > sure none of the arguments are uninitialized (might contain junk data > that never has a terminator). > Consider using snprintf instead of sprintf, since it shouldn't write > over the buffer if used correctly. > > What happens is, sprintf will gladly copy more into the buffer than it > can hold. The buffer sits in memory right next to where the arguments > are stored (in the "stack"), so they get written over once sprintf has > gone beyond the buffer. So your arguments basically contain junk now. > So the memory's corrupt, and that's all gdb has when it goes to drop > a core. > >> act_comm.c:108:48: New fresh storage (type char *) passed as implicitly >> temp >> (not released): capitalize(ch->name) >> A memory leak has been detected. Storage allocated locally is not >> released >> before the last reference to it is lost. (Use -mustfreefresh to inhibit >> warning) > > Take everything splint tells you with a grain of salt. :) > It's not super smart, it's just looking for things that statistically > often cause problems. Use it to find areas of the game to double > check. > > --Palrich. > -- > ROM mailing list > [email protected] > Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom > -- ROM mailing list [email protected] Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom
