🚀 go-pugleaf

 > From: uunet!inel.gov!dob (Dave Brooks)
 > To: epoch@cs.uiuc.edu
 > Subject: Epoch 3.2 on the DECstation (again)
 > Date: Fri, 15 Feb 91 15:14:16 -0700
 >
 >
	...
 > Epoch crashes in line 100 of xresource.c, in the
 > make_Xresource function, on this line of code:
 >
 > 	xr_free_list = XXRESOURCE(xr_free_list->next);
 >
 > printing xr_free_list from within gdb says that it is an invalid address,
 > out of bounds.  is there anything i can do to fix this?  does someone on
 > the Epoch team, or another expert, have a clue?
 >
	...

	Yes - this is a canonical bug experienced on all machines
which have DATA_SEG_BITS defined.  These machines, which in
compilation include one of the following machine definition files:
{m-88k.h, m-convex.h, m-cydra5.h, m-hp9000s800.h, m-ibmps2-aix.h,
m-ibmrt-aix.h, m-ibmrt.h, m-iris4d.h, m-pmax.h, and m-titan.h } have
their data segment originating at some high virtual address.  For example,
the mips machines have a virtual layout as follows:

  +----------+
  |    0x0   | Illegal address space
  |    ...   |
  |0x003fffff|
  +----------+
  |0x00400000| Text segment
  | ...	     |
   vvvvvvvvvv

  +----------+
  |0x10000000| Data segment
  |   ...    |
   vvvvvvvvvv

   ^^^^^^^^^^
  |   ...    |
  |0x7fffffff| Grow to zero stack segment
  +----------+
  |0x80000000| Illegal (kernel) address space
  |    ...   |
  |0xffffffff|
  +----------+

	Emacs ( and epoch ) use the high 5 or so bits of a Lisp
pointer to hold type information. (Buffer, window, function, et
cetera). When derefencing a Lisp pointer, emacs et. al. use various
macros, like the XXRESOURCE() macro call above.  These macros remove
the type information, and then OR in the DATA_SEG_BITS. 

	The problem comes in checking for the null pointer. On
machines for which DATA_SEG_BITS is not defined, all null pointers
have the value 0x0.  On machines with DATA_SEG_BITS defined, pointers
must be carefully checked for null.

	In particular, look at the code in the first patch below.  It 
removes an element from the head of a list, setting the head pointer
to be XXRESOURCE(head->next).  
	Now consider what happens if head->next is 0x0.  Our
XXRESOURCE() macro will remove type info, and then OR in
DATA_SEG_BITS. 
	This results in changing 0x0 to 0x10000000 on mips based
machines.  This in itself is not enough to cause a segmentation fault,
as 0x10000000 is a valid address, albeit most likely not one on the
xr_free_list.  The segmentation fault occurs when you call this
function again, and it tries to follow (0x10000000)->next, which
points who knows where...

	Here is a patch for the two of these cases that I've
discovered: ( note the second one applies to regular emacs 18.55 as well)

mac@gold 18 % diff -cbr dist/epoch-3.2/src/xresource.c epoch-3.2/src/xresource.c
*** dist/epoch-3.2/src/xresource.c	Tue Oct 16 11:45:13 1990
--- epoch-3.2/src/xresource.c	Wed Jan 16 18:24:33 1991
***************
*** 96,102 ****
      register Lisp_Object val;
      register struct Lisp_Xresource *xr;
  
!     if (xr_free_list)
  	{
  	xr = xr_free_list;
  	xr_free_list = XXRESOURCE(xr_free_list->next);
--- 96,102 ----
      register Lisp_Object val;
      register struct Lisp_Xresource *xr;
  
!     if (XUINT(xr_free_list)) /* Machines with DATA_SEG_BITS need this */
  	{
  	xr = xr_free_list;
  	xr_free_list = XXRESOURCE(xr_free_list->next);
mac@gold 25 % diff -cbr dist/epoch-3.2/src/buffer.c epoch-3.2/src/buffer.c
*** dist/epoch-3.2/src/buffer.c	Thu Oct 18 17:21:22 1990
--- epoch-3.2/src/buffer.c	Tue Feb 19 10:24:56 1991
***************
*** 851,857 ****
    if (c == p)
      return;
  
!   if (w)
      swb = NULL (selected_window) ? 0 : XBUFFER (w->buffer);
  
    if (p && NULL (p->name))
--- 851,857 ----
    if (c == p)
      return;
  
!   if (selected_window)
      swb = NULL (selected_window) ? 0 : XBUFFER (w->buffer);
  
    if (p && NULL (p->name))
mac@gold 26 % 

-----------+---------------------------------------------------------------------
mac@kpc.com|"Adding an option is undesirable because Emacs has too many already."
           |	        Richard M. Stallman <9009070241.AA25315@pogo>	         
-----------+---------------------------------------------------------------------