Subject: Re: The _weirdest_ segfault...
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 05/17/2000 22:25:48
> Yes, but it's not the writes or reads that segfaults, it's malloc()
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
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
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B