[net.emacs] Storage allocation bug in Gosling emacs

thomas%utah-cs@sri-unix.UUCP (11/09/83)

From:  thomas@utah-cs (Spencer Thomas)

Gosling emacs #264 bug and fix:

We have been occasionally having emacs "crashes" which seem to be caused by
freeing an allocated area twice.  Usually, it would crash in ProgN,
trying to free a variable binding, but if you looked at the storage
block, it was already free.  We turned on debug and range checking in
malloc (after fixing bugs in these), and the crashes got much more
frequent (especially freeing an already free area).  Finally got one in
"CompareReturn" in arithmetic.c.  Upon looking around, I decided that if
a comparison got an error evaluating its second argument, and the first
argument was a string valued variable, that it could cause a double
free.  The problem was that an old value could hang around in a global
variable, making it think that it needed to free it.  The solution was
to zero the pointer after calling free.  I can't make it crash (at least
the same way), now.  This problem does not appear to be in Emacs #85
because it didn't call CompareReturn if CompareSetup failed, but it
wouldn't hurt to insert this fix, I'm sure.

BTW, can anybody tell me how to transmit information like this to
UniPress?  

Here is a diff listing, the line numbers will be a little off:

RCS file: RCS/arithmetic.c,v
retrieving revision 3.2
diff -c -r3.2 arithmetic.c
*** /tmp/,RCSt1001335	Wed Nov  9 12:55:07 1983
--- arithmetic.c	Wed Nov  9 11:53:08 1983
***************
*** 378,383
  CompareReturn (val) {
      ReleaseExpr (MLvalue);
      if(GLeftS) free(GLeftS);
      MLvalue -> exp_type = IsInteger;
      MLvalue -> exp_int = val;
  }

--- 378,384 -----
  CompareReturn (val) {
      ReleaseExpr (MLvalue);
      if(GLeftS) free(GLeftS);
+     GLeftS = 0;
      MLvalue -> exp_type = IsInteger;
      MLvalue -> exp_int = val;
  }

thomas%UTAH-GR%utah-cs@sri-unix.UUCP (11/10/83)

From:  thomas%UTAH-GR@utah-cs (Spencer W. Thomas)

This little mlisp program makes our emacs die every time with an assert failure
in free.  We're using the Caltech malloc (which comes with 4.2, but the 
distributed version is really buggy in the RCHECK code - we've got fixes), it
may not cause other mallocs to die immediately, but it DOES cause a duplicate
free.  

(progn 
    (= "foo" "bar")
    (= "lkajdl;fkja;ldlfjalskdjflaskdjfl;aksjdf" (error-message "----------------"))
)

=Spencer