guy@auspex.auspex.com (Guy Harris) (10/29/89)
The fix in part 1 lets "rofftext" get far enough to "malloc" something and
discover that it's not aligned on an 8-byte boundary. The way it seems
to discover this is to do an "std" ("store double") instruction, which
requires 8-byte alignment....
"double"s on SPARC require 8-byte alignment (I assume somebody down
there is doing floating-point arithmetic somewhere). Unfortunately, the
Andrew "malloc" doesn't guarantee 8-byte alignment on SPARC; it needs to
do so.
I tried fixing it to do so, but the "obvious" fix - namely, defining
WORD as 8, and padding "struct hdr" to a multiple of 8 bytes, on a SPARC
- didn't work; it dropped core in FlushFree. The comment at the front
of "imalloc.h" says
/*
* a different implementation may need to redefine
* INT WORD BLOCK ACTIVE PREACTIVE
* where INT is integer type to which a pointer can be cast
* and INT is the number of bytes given by WORD
* WORD needs to be at least 4 so there are two zero bits
* at the bottom of a Size field
*/
which indicates that more may have to be done than just bumping WORD. I
didn't see anything obvious that would break there, though, except
perhaps for the definition of PREVFRONT.
So I just gave up and told it not to use the Andrew "malloc", which
seems to have fixed "rofftext", at least. (The original symptom was
that "help", when asked for help on some UNIX item, blew up while trying
to "rofftext" the manual page.) You patch "config/sun4_40/system.h":
*** system.h.dist Tue Oct 3 06:59:54 1989
--- system.h Sat Oct 28 16:02:58 1989
***************
*** 19,24 ****
--- 19,29 ----
#define NDBM_ENV 1
+ /*
+ * Sorry, until the Andrew "malloc" aligns stuff on 8-byte boundaries,
+ * it's not legal for SPARC.
+ */
+ #undef ANDREW_MALLOC_ENV
/* Now follow the site-specific customizations. */
#include <site.h>
There may be other Sun-4 core dumps caused by the same "malloc" bug.