Would it work just as well to do like the following?
if ( !str_cmp(word,"Clan") )
{
char name[MIL] = fread_string(fp);
ch->clan = clan_lookup(name);
fMatch = TRUE;
break;
}
That way it only allocates to a stack variable, and you have no need to
free
anything afterwards.
- Valnir
----- Original Message -----
From: "Michael Barton" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, April 07, 2005 7:03 AM
Subject: Re: Memory issues.
> 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
>>
> --
> 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
