Well, the memory for that allocation won't be freed before it's done being used, as do_function will wait for the function to return before freeing that chunk, at which point it's done being used... if, for some reason, the function being called were to free the memory internally before returning to do_function, then you would just get a warning in your log that free_string tried to free an invalid size of <whatever>... your revised function looks like it would be ok as well, except that it will allocate the memory for command_string at boot time, even if do_function was never called during gameplay... the current method ensures that memory is only allocated for the command_string if do_function is called... since it's only 1 variable that's MSL in size, it won't really impact performance any, as tons of do_func's allocate multiple variables of that size at boot time...
Richard Lindsey. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Valnir Sent: Wednesday, April 06, 2005 10:57 AM To: [email protected] Subject: Re: Memory issues. Well.. I think I found ONE of my problems.. It's in the function "do_function". /* function to keep argument safe in all commands -- no static strings */ void do_function (CHAR_DATA *ch, DO_FUN *do_fun, char *argument) { char *command_string; /* copy the string */ command_string = str_dup(argument); /* dispatch the command */ (*do_fun) (ch, command_string); /* free the string */ free_string(command_string); } Umm.. is it just me, or does this seem a little wasteful to allocate memory that could get released before it's done being used? I also posted my REVISED version, please tell me if it makes more sense. /* function to keep argument safe in all commands -- no static strings */ void do_function (CHAR_DATA *ch, DO_FUN *do_fun, char *argument) { char command_string[MSL]; /* copy the string */ strcpy( command_string, argument ); /* dispatch the command */ (*do_fun) (ch, command_string); } - Valnir ----- 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
