Re: Crash in Gimp 1.1.7 on Solaris 8.
[EMAIL PROTECTED] wrote:
> On 23 Feb, Ludovic Poitou wrote:
>
> > SunOS bondi 5.8 Generic sun4u sparc SUNW,Ultra-5_10
> > UltraSPARC-IIi
>
> > But I haven't compiled with the 64 bit flag on !
>
> > A simple program like this :
> > main(){
> > printf("%d\n", sizeof(unsigned char *));
> > }
>
> Do the plugins work for you? We've got dozens of problems with
> GIMP on 64bit architectures not using gcc for compilation.
>
I tried several plugins and they all work.
Ludovic.
>
> --
>
> Servus,
>Daniel
--
Ludovic Poitou
Sun Microsystems Inc.
iPlanet E-Commerce Solutions - Directory Group - Grenoble - France
Re: Crash in Gimp 1.1.7 on Solaris 8.
On 23 Feb, Ludovic Poitou wrote:
> SunOS bondi 5.8 Generic sun4u sparc SUNW,Ultra-5_10
> UltraSPARC-IIi
> But I haven't compiled with the 64 bit flag on !
> A simple program like this :
> main(){
> printf("%d\n", sizeof(unsigned char *));
> }
Do the plugins work for you? We've got dozens of problems with
GIMP on 64bit architectures not using gcc for compilation.
--
Servus,
Daniel
Re: Crash in Gimp 1.1.7 on Solaris 8.
In regard to: Re: Crash in Gimp 1.1.7 on Solaris 8., Ludovic Poitou said...:
>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-IIi
>
>But I haven't compiled with the 64 bit flag on !
>
>A simple program like this :
>main(){
>printf("%d\n", sizeof(unsigned char *));
>}
>
>returns 4 !
Then my guess about what the problem is (for you, anyway) isn't correct.
It's still a problem for LP64 OSes, 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
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-IIi
But 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
Re: Crash in Gimp 1.1.7 on Solaris 8.
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
