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
