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
