Re: Memory issues.

No, this won't work.  fread_string allocates a string and returns it,
so you'll still need to free it.  You could write a function to read
in a string and return in a static buffer instead of an allocated
string, but I don't know if it'll be all that useful.

On Apr 7, 2005 8:24 AM, Valnir <[email protected]> wrote:
> 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:
> >> >> 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
> >>
> > --
> > 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