> According to g_int64_equal documentation, it expects its arguments to > be pointers to gint64 values, which on sparc must be aligned on an > 8-byte boundary. Looks like this is intentional, because > nbd-tester-client.c creates its hash table like that: > > That's odd that it would be 4-byte aligned...local variables are aligned on natural boundaries on both GCC and Sun CC, malloc() on both Solaris and Linux returns 8-byte aligned pointers, and structure members generally alignment members on their natural boundary anyway to prevent crashes. The only way to get an unaligned integer pointer aside from horribly pathological cases is to do try to malloc() two things separately without any consideration of the alignment between the two, e.g. a 32-bit integer and 64-bit integer:
char* data = malloc(sizeof(uint32_t) + sizeof(uint64_t)); uint64_t* ptr = (uint64_t)(data + sizeof(uint32_t)); *ptr = 0; //likely crash Patrick > GHashTable *handlehash = g_hash_table_new(g_int64_hash, g_int64_equal); > > The 'key' pointer (0xffffd104) passed to g_hash_table_lookups > from nbd-tester-client.c:1103 points to a location which is only > 4-bytes aligned, causing the crash. > > Best regards, > -- > Jurij Smakov ju...@wooyd.org > Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC > > > -- > To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/20120303090317.ga5...@wooyd.org > >
