> Yes, but it's not the writes or reads that segfaults, it's malloc()
> itself!

Right.  Corrupt someone else's internal data structures and that
someone else is liable to segfault on you.  It just so happens that
overrunning malloc()ed space is very likely to corrupt malloc()'s
internal data structures, because they're kept in memory adjacent to
the malloc()ed memory.

> The shell works perfectly on FreeBSD/x86 where it was developed, the
> problem is only on the Alpha!

It could be that...

- FreeBSD's malloc() may lay out its internal data structures
   differently, such that it happens to not mind the corruption.

- The overrun itself could be present only on the alpha, due to an
   alpha/x86 difference.  As a simple example, if you write

	int **ivp;

	ivp = malloc(n * sizeof(int)); /* should be sizeof(int *) */
	...ivp[i] = something...

   then it will "work perfectly" on a machine - like the x86 - where
   sizeof(int) == sizeof(int *), but fall over hard on a machine - like
   the alpha - where sizeof(int) < sizeof(int *).  (And on a machine
   where sizeof(int) > sizeof(int *), it will work but waste space.)

- The value-trashing could be happening on any machine but might happen
   to be non-deadly on the x86.  For example, an long could overflow 32
   bits and end up zero on the x86, be dropped on top of a pointer, and
   thereby turn it into a nil pointer (which, though incorrect, might
   be something the implementation could tolerate).  But if the
   overflow overflows 32 bits but not 64 bits, the result on the alpha
   could be a non-nil but garbage pointer, which the implementation
   might *not* be able to tolerate.

You might play with the MALLOC_OPTIONS environment variable - in
particular, strings I recommend trying include AJ and AZ; you might
also try adding the V and/or X options.  See the man page for malloc
for more.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B