Holy crap!
And this is why I fully admit to the fact that I am still learning, and
don't know a lot about the memory process.
We had several items (in free_char, free_note, and free_pcdata) that
where
not being freed, including material.
Guess I need to go check free_obj too, now that I'm thinking about it.
That in itself should help the memory growth GREATLY. Thanks for pointing
that out.
So on the topic of "KEY( "Clan", ch->clan,
clan_lookup(fread_string(fp)));", what do you suggest to do with this
line?
- Valnir
----- Original Message -----
From: "Michael Barton" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, April 06, 2005 12:46 PM
Subject: Re: Memory issues.
> 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
>>
> --
> 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
