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 = "" + 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 jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120303090317.GA5035@wooyd.org" target="_blank">http://lists.debian.org/20120303090317.GA5035@wooyd.org