Yeah.
The memory usage going up during a fight may not mean much, it could
have just been an area resetting or something. I'd go the gdb route
too, it's more better.
And you'll want to play the game for a bit before you do it.. make
sure all the areas are fully reset, kill a few mobs, etc. Basically
try and build up a pool of free memory so no new allocations should be
happening.
You should make sure all the known stock problems are taken care of.
Like off the top of my head, ch->material isn't freed in free_char and
it should be.
Then from save.c, fread_string returns an allocated string and this
just throws it away.
KEY( "Clan", ch->clan, clan_lookup(fread_string(fp)));
Has anyone made a list of these?
--Palrich.
On Apr 6, 2005 11:17 AM, Richard Lindsey <[EMAIL PROTECTED]> wrote:
> Ok, well the explanation for attaching to the process is below, but I'll
> restate it along w/ what you should do for monitoring memory allocation,
> and I'll refer you to my gdb tutorial on frostmud.com again :D
>
> From the shell, do a "ps ux" or "ps -ux", depending on your flavor of
> Linux... you'll get output similar to the following:
>
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> loa 27648 0.0 0.1 5108 1164 ? S Mar26 0:00 /bin/csh
> -f ./test 9001
> loa 27650 0.3 0.8 14488 8336 ? S Mar26 56:22
> ../src/rom 9001
> loa 27651 0.0 0.1 10808 1288 ? S Mar26 0:00 aspell -a
> loa 27286 0.1 0.2 8316 2260 ? S 12:11 0:00 sshd:
> [EMAIL PROTECTED]/457
> loa 27287 0.2 0.1 6272 1360 pts/457 S 12:11 0:00 -bash
> loa 27360 0.0 0.0 3728 744 pts/457 R 12:11 0:00 ps ux
>
> The column labeled PID is where you want to focus, find the PID for the
> line that has your executable running, in this case it's the line that
> says ../src/rom 9001, so the PID is 27650...
>
> Then, cd into that directory and type this:
>
> gdb ./rom 27650
>
> That will load gdb and attach it to your running mud's process... once
> inside, type this:
>
> watch nAllocPerm
> continue
>
> that will set a watchpoint for nAllocPerm, which is the internal
> variable that ROM uses for tracking how many permanent memory blocks
> it's allocated, and it's case sensitive... the continue tells the mud to
> start executing again, as it gets paused when gdb is first loaded... now
> flip over to your mud window again and get into a fight with a mob...
> when the game freezes, flip back over to your shell window, gdb should
> be showing a line like so:
>
> Hardware watchpoint 1: nAllocPerm
>
> Old value = 71918
> New value = 71919
> alloc_perm (sMem=36) at db.c:3263
> 3263 sAllocPerm += sMem;
> (gdb)
>
> that's where the mud is assigning a new chunk of memory, now type 'bt'
> to get a backtrace...
>
> #0 alloc_perm (sMem=36) at db.c:3263
> #1 0x080e9261 in new_note () at recycle.c:152
> #2 0x080d1792 in note_attach (ch=0xf6b32798, type=-156028424) at
> note.c:509
> #3 0x080d2940 in parse_note (ch=0xf6b32798, argument=0xfeed7828 "all",
> type=0) at note.c:1107
> #4 0x080d1259 in do_note (ch=0xf6b32798, argument=0xfeed7825 "to all")
> at note.c:122
> #5 0x080b7d1b in interpret (ch=0xf6b32798, argument=0xfeed7825 "to
> all") at interp.c:725
> #6 0x08080c32 in substitute_alias (d=0xf6b2b21c, argument=0xfeed7820
> "note to all") at alias.c:125
> #7 0x08090b11 in game_loop_unix (control=4) at comm.c:880
> #8 0x0809056c in main (argc=2, argv=0xfeedb2f4) at comm.c:659
>
> in my case, I just went into my mud and did a 'note to all' which has to
> allocate new memory for the note_data... you can see in frame 1 where it
> calls new_note()... you'll want to follow this same set of steps on
> yours, and try to find where it's calling for more memory... when you're
> done looking, you can type continue, and the mud will keep going again,
> and stop on the next time new memory is being allocated... you may want
> to capture a few instances of those backtraces (only the first few lines
> of them, sometimes it can be spammy :D) and post the output here, along
> w/ a description of what you were doing at the time, fighting or
> whatever... when you're ready to get back out of gdb and let the mud run
> normally, just type q at a gdb prompt and you'll see something like
> this:
>
> The program is running. Quit anyway (and detach it)? (y or n) y
> Detaching from program: /home/loa/test/Rom24/src/rom, process 27650
>
> Richard Lindsey.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Valnir
> Sent: Wednesday, April 06, 2005 11:07 AM
> To: [email protected]
> Subject: Re: Memory issues.
>
> Ok.. because I'm GDB ignorant, could you explain how to attach it to a
> running process, and how to monitor stuff? When it come to GDB I know
> two
> things.. "gdb -c core ../src/rom" and "where" once I'm inside.
>
> Thanks a million!
>
> - V
>
> ----- Original Message -----
> From: "Richard Lindsey" <[EMAIL PROTECTED]>
> To: "Valnir" <[EMAIL PROTECTED]>; <[email protected]>
> Sent: Wednesday, April 06, 2005 11:17 AM
> Subject: RE: Memory issues.
>
> In that case it could be something in your output during combat that's
> allocating a string and not freeing it, and those would add up w/ each
> battle round... try attaching gdb and monitoring nAllocPerm and see when
> it goes up, then backtrace and find out why, feel free to post some gdb
> output here if you want, but if you do, try to include it from a few
> separate instances of nAllocPerm increasing, so we can see if it's from
> 1 common cause or perhaps multiple...
>
> Richard Lindsey.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Valnir
> Sent: Wednesday, April 06, 2005 10:15 AM
> To: [email protected]
> Subject: Re: Memory issues.
>
> While I understand the point of new objects, re-pops, etc.. the mem when
> up
> DURING the fight, not a big jump AFTER.
>
> - V
>
> ----- Original Message -----
> From: "Richard Lindsey" <[EMAIL PROTECTED]>
> To: "Valnir" <[EMAIL PROTECTED]>; <[email protected]>
> Sent: Wednesday, April 06, 2005 11:07 AM
> Subject: RE: Memory issues.
>
> 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
>
> --
> 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
> --
> ROM mailing list
> [email protected]
> Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom
>
