Re: Checking Memory...

From: Zeavon (zeavon@kilnar.com)
Date: 09/25/00


On Mon, 25 Sep 2000, Deja Augustine wrote:

> When sedit tries to save it internally, it calls various functions to
> transfer the data over into the "real" memory of the MUD, rather than the
> temporary one it was in.  However, it seems that the usual safeguards are
> failing in determining when the temporary one can be freed.
>
> >From using GDB and a series of self-inflicted, crashing scenarios, I've
> discovered that when the code does something like:
>   if(*tlist)   or    if(shop->blah_string)
>
> they will evaluate to true, even if the memory they point to doesn't "exist"
> anymore, or never existed in the first place.  So, when it tries to free the
> pointers, the program has a heart-attack and dies.

free() does not set a pointer to NULL, so something like this:

struct shop_data *shop;              // define shop
CREATE(shop, struct shop_data, 1);   // allocate mem
shop->vnum = 300;                    // set room num
// Do some other stuff w/ shop
free(shop);                          // free mem

if (*shop)                           // will always be true.
  send_to_char("True.\r\n", ch);
else
  send_to_char("False.\r\n", ch);

-------
To fix this, you need to make sure and always set the pointer to NULL
after freeing a structure. Something like this:

struct shop_data *tmp;
CREATE(tmp, struct shop_data, 1);
free(tmp);
tmp = NULL;



This information is a bit rusty in my head... I've been dealing with C++
(new/delete) lately so make sure and run your own tests on the code to
make sure that it does what you think it is supposed to do.

--
Zeavon Calatin, MageMaster of the Realms
Spear of Insanity
http://spear.kilnar.com/    telnet://spear.kilnar.com:1066


     +------------------------------------------------------------+
     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html  |
     +------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 04/11/01 PDT