In regard to: Crash in Gimp 1.1.7 on Solaris 8., Ludovic Poitou said (at...:

>signal BUS (invalid address alignment) in color_pixels at 0x177858
>color_pixels+0x110:     ld      [%l0], %i1

You don't say what architecture you're running on, but Solaris 7 or later on
an Ultra would be a LP64 (i.e. 64 bit) OS, so an invalid address alignment
would be indicative of incorrect alignment of a pointer.  I'm not certain,
but odds are good that pointers in Solaris 8 must be aligned on 8-byte
boundaries, as opposed to ints which could be aligned on 4-byte boundaries.

>  register unsigned char c0, c1, c2;
>  register guint32 *longd, longc;
>  register guint16 *shortd, shortc;

I can't tell by the code what the intent is, but these definitions have
longd as a pointer (an 8-byte quantity on LP64 machines) while longc is
an unsigned 32-bit quantity (*not* a pointer).  Ditto for shortd and shortc.

>  switch (bytes)
>  {
>   case 1:
>     memset(dest, *color, w);
>     break;
>   case 2:
>     shortc = ((guint16 *)color)[0];

This is probably also a problem here -- shortc isn't big enough to hold
an address.

>     shortd = (guint16 *)dest;
>     while (w--)
>     {
>       *shortd = shortc;
>       shortd++;
>     }
>     break;
>   case 3:
>     c0 = color[0];
>     c1 = color[1];
>     c2 = color[2];
>     while (w--)
>     {
>       dest[0] = c0;
>       dest[1] = c1;
>       dest[2] = c2;
>       dest += 3;
>     }
>     break;
>   case 4:
>     longc = ((guint32 *)color)[0];   <<<< Crash here !

longc is a 32 bit quantity, which isn't big enough to hold an address on
LP64 machines.   That's probably why you're getting the crash.  I bet I
would get the same result (or at least an "unaligned access" warning) on
my Tru64 Unix box.

>     longd = (guint32 *)dest;
>     while (w--)
>     {
>       *longd = longc;
>       longd++;
>     }
>     break;
>   default:
>   {
>     int b;
>     while (w--)
>     {
>       for (b = 0; b < bytes; b++)
>         dest[b] = color[b];
>
>       dest += bytes;
>     }
>   }
>  }
>}

I'm not sure what the right fix is, being I haven't looked long enough at
the code to decipher what's going on.  The problem is almost certainly a 32 bit
vs. 64 bit issue, though.

Tim
-- 
Tim Mooney                              [EMAIL PROTECTED]
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J1, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

Reply via email to