-----Ursprüngliche Nachricht-----Hey man,
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Ludovic Poitou
Gesendet: Donnerstag, 24. Februar 2000 14:13
An: Daniel H.
Betreff: Re: AW: Crash in Gimp 1.1.7 on Solaris 8.Relax,
You are registered on a public mailing list : [EMAIL PROTECTED]
If you don't want to receive mails from this mailing list, unsubscribe.
Otherwise, you will keep on receiving emails.
If you're too dumb to figure this out, unplug your PC and you'll never get any further mails !Ludovic.
"Daniel H." wrote:
don't wirte me Again!!!!!!!!!! I've never mailes you!!!! It was a joke from
a other person!!!!don't wirte me Again!!!!!!!!!! I've never mailes you!!!!
It was a joke from a other person!!!!don't wirte me Again!!!!!!!!!! I've
never mailes you!!!! It was a joke from a other person!!!!don't wirte me
Again!!!!!!!!!! I've never mailes you!!!! It was a joke from a other
person!!!!don't wirte me Again!!!!!!!!!! I've never mailes you!!!! It was a
joke from a other person!!!!-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag
von Ludovic Poitou
Gesendet: Mittwoch, 23. Februar 2000 19:35
An: Tim Mooney
Cc: Ludovic Poitou; [EMAIL PROTECTED]
Betreff: Re: Crash in Gimp 1.1.7 on Solaris 8.Tim Mooney wrote:
> 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.
>SunOS bondi 5.8 Generic sun4u sparc SUNW,Ultra-5_10
UltraSPARC-IIiBut I haven't compiled with the 64 bit flag on !
A simple program like this :
main(){
printf("%d\n", sizeof(unsigned char *));
}returns 4 !
Ludovic.
>
> > 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-- Ludovic Poitou Sun Microsystems Inc. iPlanet E-Commerce Solutions - Directory Group - Grenoble - France
