Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
Bug in get_exp_worth( )
Oct 10, 2017, 1:26 am
By GatewaySysop
Bug in do_drag( )
Oct 8, 2017, 12:40 am
By GatewaySysop
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Beastmaster 6D sound files
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, Yahoo!, DotBot

Members: 0
Guests: 4
Stats
Files
Topics
Posts
Members
Newest Member
476
3,704
19,231
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SmaugFUSS » Leak - do_skin
Forum Rules | Mark all | Recent Posts

Leak - do_skin
< Newer Topic :: Older Topic > leak do_skin

Pages:<< prev 1 next >>
Post is unread #1 Oct 15, 2014, 6:10 am
Go to the top of the page
Go to the bottom of the page

Matteo2303
Apprentice
GroupMembers
Posts57
JoinedAug 25, 2003

In do_skin
OBJ_DATA *korps
...seems rest in void after create_object.

probably is better
OBJ_INDEX_DATA *korps;
and use simply get_index_data withous create_object.

bye
mat
       
Post is unread #2 Oct 15, 2014, 8:25 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,857
JoinedJul 26, 2005

good catch, seems it has been over looked in here lol.
       
Post is unread #3 Oct 15, 2014, 11:38 pm   Last edited Oct 16, 2014, 3:09 am by Matteo2303
Go to the top of the page
Go to the bottom of the page

Matteo2303
Apprentice
GroupMembers
Posts57
JoinedAug 25, 2003

I also noticed other leaks but I should check if they concern only my old smaugfuss and perhaps consequent to my extra implementations, or if errors are also present in the latest versions.

For example: I noticed a thing that on MY code generated a leak on the hash table:

            if( !str_cmp( word, "Class" ) )
            {
               arg = fread_string( fp );
               while( arg[0] != '\0' )
               {
                  arg = one_argument( arg, temp );
                  for( i = 0; i < MAX_PC_CLASS; i++ )
                     if( !str_cmp( temp, class_table[i]->who_name ) )
                     {
                        SET_BIT( morph->Class, ( 1 << i ) );
                        break;
                     }
               }
               fMatch = TRUE;
               break;
            }


In my codebase yellow line allocates in the hash_table the contents of the line "Class" present in the morphs.dat. However, the value of arg wetsuit because of one_argument (blue line), and so, even if they wanted to make one final STRFREE, arg doesn't match the original string stored in hash_table. I solved trivially doing some sort of local swap ...

char buf[MSL];
arg = fread_string( fp );
if (!arg){fMatch=TRUE;break;}
sprintf( buf, "%s", arg );
STRFREE(arg); 
arg = buf;


Similar situation in the various:

void mprog_mead_programs( FILE *fp, MOB_INDEX_DATA *pMobIndex)
void oprog_read_programs( FILE *fp, MOB_INDEX_DATA *pMobIndex)
void rprog_read_programs( FILE *fp, MOB_INDEX_DATA *pMobIndex)

but in these cases are almost certain to be due to an old implementation of "in_file_prog" present in my version.

	
char *tempstring;
mprg = mprog_file_read( (tempstring=fread_string( fp )), mprg,pMobIndex );
	if ( tempstring ) STRFREE(tempstring);


I noticed these things by implementing my own version of cleanup_memory.
And also, about the close_area: I realized that the various low_r_vnum, low_o_vnum and low_m_vnum assume that the first area is vnum the lowest. This is reasonable but it is not always so. And in the "close_area" if the low_x_vnum is not properly set, the IndexData object / mob / room are not all cleaned up as would be expected.

in my case i prefear change for example:

if ( !tarea->low_m_vnum )
		   tarea->low_m_vnum	= vnum;


with:

		   if ( !tarea->low_o_vnum || vnum < tarea->low_o_vnum )
		   tarea->low_o_vnum	= vnum;



...and in any case I have implemented a linked-list that allows the object to point directly to where it belongs which I think is the best thing in some portions of code as that of the close area.

Instead of things like:

    for ( oid = obj_index_hash[icnt]; oid; oid = oid_next )
    {
      oid_next = oid->next;
      
      if ( oid->vnum < pArea->low_o_vnum || oid->vnum > pArea->hi_o_vnum )
      continue;


I use:

    for ( oid = obj_index_hash[icnt]; oid; oid = oid_next )
    {
      oid_next = oid->next;
      if ( oid->area != pArea )
      continue;


bye
mat
       
Post is unread #4 Oct 19, 2014, 8:50 am
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,857
JoinedJul 26, 2005

Ok fixed it in do_skin and fread_morph, thanks for finding and reporting them :)
       
Post is unread #5 Oct 26, 2014, 1:22 am
Go to the top of the page
Go to the bottom of the page

GatewaySysop
Conjurer
GroupMembers
Posts367
JoinedMar 7, 2005

Remcon said:

Ok fixed it in do_skin and fread_morph, thanks for finding and reporting them :)


Seconded! Very good catches Matteo, thanks for posting and sharing them. Gave me a reason to dig back into my codebase for the first time in a long while. :wink:

       
Pages:<< prev 1 next >>