Re: Memory issues.

Yeah, I noticed when I tried it.. hehe

One question though.. I tried the "char *temp;" and "free_string(temp);" 
thing in the Skill section of fread_char and it came back with "[*****] BUG: 
Attempt to recycle invalid memory of size 4." and "[*****] BUG: axe". Any 
thoughts?

            if ( !str_cmp( word, "Skill" ) || !str_cmp(word,"Sk") )
            {
                int sn;
                int value = fread_number( fp );
                char *temp = fread_word( fp );

                sn = skill_lookup(temp);

                if ( sn < 0 )
                {
                    sprintf(buf, "Fread_char: unknown skill - %s",temp);
                    bug( buf, 0 );
                }
                else
                    ch->pcdata->learned[sn] = value;

                free_string(temp);
                fMatch = TRUE;
            }


- Valnir

----- Original Message ----- 
From: "Michael Barton" <[email protected]>
To: <[email protected]>
Sent: Thursday, April 07, 2005 10:03 AM
Subject: 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
> 


-- 
ROM mailing list
[email protected]
Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom