Re: Memory issues.

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:
>> loa@pts/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