Mine went something like this...
if (!strcasecmp(word, "Clan"))
{
char *temp = fread_string(fp);
ch->clan = clan_lookup(temp);
free_string(temp);
fMatch = TRUE;
break;
}
Also this one needs fixing:
KEY( "Race", ch->race,
race_lookup(fread_string( fp )) );
And any others that use fread_string should probably use the KEYS
macro instead of the KEY macro. They aren't necessarily memory leaks,
but KEYS is a backup to help prevent them. Example:
- KEY( "Desc", pet->description, fread_string(fp));
+ KEYS( "Desc", pet->description, fread_string(fp));
On Apr 7, 2005 5:33 AM, Valnir <[EMAIL PROTECTED]> wrote:
> 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
>
