Am Mittwoch, den 05.11.2008, 08:45 +0100 schrieb Fred Kiefer: > Riccardo is having trouble with the new icns loading code on sparc > architecture. I think this is caused by pointers into the data structure > not being properly aligned for this processor, but as I am no expert in > this area it would be great if somebody could have a look before I start > experimenting around. > > The problem he gets is: > Program received signal SIGBUS, Bus error. > 0x0fec17e4 in icns_import_family_data (size=33658, bytes=0x9a6e000 "icns", > iconFamily=0xf7fca660) at NSBitmapImageRep+ICNS.m:270 > 270 while ((data < end) && element->elementSize) > > > (gdb) p data > $1 = (icns_byte_t *) 0xdce6372 "t8mk" > (gdb) p end > $2 = (icns_byte_t *) 0xdcea37a "" > (gdb) p element->elementSize > $3 = 16392
Given the definitions of the types: typedef unsigned char icns_byte_t; typedef unsigned long icns_size_t; typedef struct _icns_type_t { char c[4]; } icns_type_t; typedef struct _icns_element_t { icns_type_t elementType; icns_size_t elementSize; } icns_element_t; typedef struct _icns_family_t { icns_type_t resourceType; icns_size_t resourceSize; icns_element_t elements[1]; } icns_family_t; I would assume the straight forward fix (if indeed it is an alignment issue is to add padding to icns_element_t to the sizeof(long) boundry which is 8 byte on most 64 bit archs. I.e. typedef struct _icns_element_t { icns_type_t elementType; char padding[4]; icns_size_t elementSize; } icns_element_t; But yeah... maybe we should just look at their code... Cheers, David _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev