Re: misalignment with DEC Unix.

[David Turner]

Hi Tom,

> 
> 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?
> 

I'm a bit surprised by this. Are you really sure that you can have
both 4-byte aligned variables and 8-bytes aligned *only* pointers ?

Could you give us the output of the following C program:

  #include <stdio.h>

  short a[3];

  int  main( void )
  {
    printf( "%p %p %p %p %d\n", a, a+1, (void*)(a+1), a+2, sizeof(a) );
  }

It would help me see things clearer..

Thanks in advance,

- David


> (*) 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
> >