misalignment with DEC Unix.

[Tom Kacvinsky]

Here is a bt from a forced core dump (*):

#0  T2_Parser_Run (parser=0x11ffff210,
    start=0xf694 <Address 0xf694 out of bounds>, limit=0x14006262e "")
    at ./src/cff/t2parse.c:530
#1  0x120010a40 in T2_Load_CFF_Font (stream=0x140060ec0, face_index=0,
    font=0x140061400) at ./src/cff/t2load.c:405
#2  0x120010e9c in T2_Init_Face (stream=0x140060ec0, face=0x140068b00,
    face_index=0, num_params=0, params=0x0) at ./src/cff/t2objs.c:127
#3  0x12000afcc in open_face (driver=0x140060860, stream=0x140060ec0,
    face_index=0, num_params=0, params=0x0, aface=0x11ffff640)
    at ./src/base/ftobjs.c:1139
#4  0x12000b220 in FT_Open_Face (library=0x140062220, args=0x11ffff668,
    face_index=0, aface=0x14000eab0) at ./src/base/ftobjs.c:1400
#5  0x12000b07c in FT_New_Face (library=0x1,
    pathname=0xf694 <Address 0xf694 out of bounds>, face_index=0,
    aface=0x140062626) at ./src/base/ftobjs.c:1214
#6  0x120009244 in main (argc=2, argv=0x11ffff888) at src/ftview.c:705

Straight-away, we see that pathname=0xf694 is not 8 byte aligned.  It
is, however, 4 byte aligned.  On the alpha, data structures occupying
less than 4 bytes are aligned on 4 bytes, otherwise they are aligned
on 8 bytes.  Or so says the DEC C comiler's manual, and points are
always 8 byte aligned.

My suspicion is that a point to char is being typecaset to a pointer
to void, so we have the misalignment right there: foo = (void *)(&c),
where c is char, yields foo (a pointer that is eight byte aligned) has
a 4 byte aligned address.

Am I making sense here?

(*) To force a core dump when a mis-aligment happens on a DEC UNIX box,
add the following code to the main procedure:

#include <sys/sysinfo.h>
#include <sys/proc.h>
.
.
.
int buf[2];

/* Crash on mis-aligned accesses (otherwise we can't find them!) */

buf[0] = SSIN_UACPROC;
buf[1] = UAC_SIGBUS;
setsysinfo(SSI_NVPAIRS, buf, 1, 0, 0);


On Tue, 27 Jun 2000, David Turner wrote:

> Werner LEMBERG a écrit :
> > 
> > > Speaking of Alphas, I tried freetype2's latest snapshot on a DEC
> > > Unix box (can't stand the name Tru64 UNIX), and got all kins of
> > > unaligned access errors.  Ghostscript used to get these all of the
> > > time, and it was because of weirdness in memory allocation
> > > (returning pointers that didn't align on an 8 byte boundary).
> > 
> > This shouldn't happen.  Can you give more details?  Some hot spots
> > where this happens?  We have an `FT_ALIGNMENT' macro (set to 8 by
> > default) which probably has to be used more often...
> > 
> 
> The FT_ALIGNEMENT macro is only used in the scan-line converter I
> believe.. The rest of the FreeType 2 code shouldn't be dependent on
> memory alignment..
> 
> We don't do any trick with memory blocks either, as ft_alloc simply
> calls the standard "malloc" in all versions of "ftsystem.c". Do you
> have a custom implementation ??
> 
> I would be interested in seeing traces of bus errors however, just
> in case :-)
> 
> - David
>