Date: Thu, 4 Mar 93 12:52:58 CST
From: (csaba AT vuse DOT vanderbilt DOT edu) <csaba AT vuse DOT vanderbilt DOT edu>
To: awandelt AT rs1 DOT thch DOT uni-bonn DOT de
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: bug in SUIT?

On Sun, 28 Feb 1993 14:56:27 +223,
  Andreas Wandelt writes:

>I am working with the SUIT library and the djgpp compiler on a PC and stumbled
>over a very nasty bug yesterday. IMHO, it must be a bug either in the
>SUIT or SRGP libraries or in djgpp/libgrx.
>
>To put it simply: At least on my system and on any other PC I tested this
>on *every* program seems to crash if it creates and destroys too many
>widgets. How many are necessary, seems to depend on the application, but
>not on the system (RAM, graphics, whatever...).
>....
>

The following patch fixes the problem for your test program. I am 
still not 100% confident in the memory management of SUIT -- but at least
this gets out one of the bugs.

The problem was in the "RecursivelyDestroy" function of "tree.c". The 
following "diff" output illustrates it.

-----------------------------------------------------------------
*** oldtree.c Thu Mar  4 17:04:58 1993
--- tree.c Thu Mar  4 17:17:12 1993
***************
*** 822,830 ****
      /* destroy all the object's properties */
      while (DynSize (o->props) > 0) {
   property *prop = (property *) DynGet (o->props, DynHigh (o->props));
!  /* SUIT_free (prop->name); */
!  /* SUIT_free (prop->type); */
!  SUIT_free (prop->value);
   DynDelete (o->props, DynHigh (o->props));
      }
      DynDestroy (o->props);
--- 822,832 ----
      /* destroy all the object's properties */
      while (DynSize (o->props) > 0) {
   property *prop = (property *) DynGet (o->props, DynHigh (o->props));
!  SUIT_type *theType = si_getType (prop->type);
! 
!  theType->destroy (prop->value);
!  /* SUIT_free (temp->name); */
!  /* SUIT_free (temp->type); */
   DynDelete (o->props, DynHigh (o->props));
      }
      DynDestroy (o->props);
-----------------------------------------------------------------

The new code (patterned after the property erase function in "property.c")
calls the property-specific destroy function, while the original code just 
'free'-d the property value. The original worked for any property whose 
value was simply 'malloc'-ed, but for some types (textlists, enums, etc...) 
it was a disaster. The only thing which saved the day in the majority of 
cases was the robustness of the BSD malloc in libc.a. It checks for a 
specific bit pattern in the allocated block header and frees it only if the 
pattern is there. But if you try enough times...


Csaba Biegl
csaba AT vuse DOT vanderbilt DOT edu