Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
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
LOP 1.45
Author: Remcon
Submitted by: Remcon
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
Users Online
CommonCrawl, Yandex

Members: 0
Guests: 16
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Bugfix Lists » SmaugFUSS Bugfix List » [Bug] Memory leak in close_ar...
Forum Rules | Mark all | Recent Posts

[Bug] Memory leak in close_area
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 Aug 26, 2005, 4:20 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Bug: Memory leak in close_area
Danger: High - Memory leak and possible list corruption
Found by: Remcon
Fixed by: Remcon

---

act_wiz.c, close_area

Locate:
   UNLINK( pArea, first_area, last_area, next, prev );
   UNLINK( pArea, first_build, last_build, next, prev );
   UNLINK( pArea, first_asort, last_asort, next_sort, prev_sort );
   UNLINK( pArea, first_bsort, last_bsort, next_sort, prev_sort );
   UNLINK( pArea, first_area_name, last_area_name, next_sort_name, prev_sort_name );


Replace with:
   if( IS_SET( pArea->flags, AFLAG_PROTOTYPE ))
   {
      UNLINK( pArea, first_build, last_build, next, prev );
      UNLINK( pArea, first_bsort, last_bsort, next_sort, prev_sort );
   }
   else
   {
      UNLINK( pArea, first_area, last_area, next, prev );
      UNLINK( pArea, first_asort, last_asort, next_sort, prev_sort );
      UNLINK( pArea, first_area_name, last_area_name, next_sort_name, prev_sort_name );
   }


Locate the function close_all_areas and replace it with:
void close_all_areas( void )
{
   AREA_DATA *area, *area_next;

   for( area = first_area; area; area = area_next )
   {
      area_next = area->next;
      close_area( area );
   }
   for( area = first_build; area; area = area_next )
   {
      area_next = area->next;
      close_area( area );
   }
   return;
}


build.c, area_flags array

Locate:
   "nopkill", "freekill", "noteleport", "spelllimit", "r4", "r5", "r6", "r7", "r8",


Change to:
   "nopkill", "freekill", "noteleport", "spelllimit", "prototype", "r5", "r6", "r7", "r8",


build.c, fold_area

Locate:
   if( ( fpout = fopen( filename, "w" ) ) == NULL )
   {
      bug( "fold_area: cant open %s", filename );
      perror( filename );
      return;
   }


Below that, add:
   if( install )
      REMOVE_BIT( tarea->flags, AFLAG_PROTOTYPE );


db.c, load_buildlist

Locate:
            pArea->weather->echo_color = AT_GREY;
            pArea->first_room = pArea->last_room = NULL;


Below that, add:
            SET_BIT( pArea->flags, AFLAG_PROTOTYPE );


mud.h

Locate:
#define AFLAG_SPELLLIMIT	    BV03


Below that, add:
#define AFLAG_PROTOTYPE             BV04


This one is relatively nasty. During bootup, the game makes several lists of areas. One for normal ones, one for prototype ones, and some sorting lists. This is fine. The problem lies with when close_area gets called for some reason. Once it does, the area being closed is arbitrarily removed from *ALL* of the lists. Well, needless to say, this doesn't do nice things to lists the area pointer isn't actually in. The UNLINK macro isn't bright enough to realize it's not there and will dutifully remove random stuff, resulting in a corrupted list and a memory leak. It became necessary to have a new bit flag to mark which ones are prototypes, and remove areas only from the lists they are actually on.
       
Pages:<< prev 1 next >>