Re: Bug#653653: nbd: FTBFS on sparc: Bus error (core dumped) - FAIL: integrity
On Fri, Mar 02, 2012 at 12:52:33AM +0100, Julien Cristau wrote: cc+=debian-sparc@ On Wed, Feb 29, 2012 at 14:14:46 +0100, Wouter Verhelst wrote: tags 653653 + help thanks On Fri, Dec 30, 2011 at 12:40:09AM +0100, Jakub Wilk wrote: Source: nbd Version: 1:2.9.25-2 Severity: serious Justification: fails to build from source User: debian-sparc@lists.debian.org Usertags: sparc nbd FTBFS on sparc: | ./integrity | 28870: Seq 0002 Queued: 0001 Inflight: Done: | Bus error (core dumped) | FAIL: integrity Full build log: https://buildd.debian.org/status/fetch.php?pkg=nbdarch=sparcver=1%3A2.9.25-2stamp=1325194394 So, I had a look at this on the porter machines a while back, and I have to say I'm a bit stumped as to what's wrong. There's some stack corruption going on inside nbd-tester-client (the test suite client that tests whether nbd-server runs correctly), which makes things a bit harder; but I can't see why there should be any such stack corruption. Running this inside valgrind (on amd64) also doesn't flag anything suspicious. Help from anyone familiar with SPARC would be appreciated. Here's a backtrace: Program received signal SIGBUS, Bus error. 0xf7f49c08 in g_int64_equal (v1=0x2bd28, v2=0xd104) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/gutils.c:3567 3567 /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/gutils.c: No such file or directory. (gdb) bt #0 0xf7f49c08 in g_int64_equal (v1=0x2bd28, v2=0xd104) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/gutils.c:3567 #1 0xf7ef529c in g_hash_table_lookup_node (hash_return=synthetic pointer, key=0xd104, hash_table=0x2b000) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/ghash.c:381 #2 g_hash_table_lookup (hash_table=0x2b000, key=0xd104) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/ghash.c:1029 #3 0x00014580 in integrity_test (hostname=optimized out, port=optimized out, name=optimized out, sock=7, sock_is_open=optimized out, close_sock=optimized out, testflags=0) at nbd-tester-client.c:1103 #4 0x00010f98 in main (argc=7, argv=0xd254) at nbd-tester-client.c:1309 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: GHashTable *handlehash = g_hash_table_new(g_int64_hash, g_int64_equal); The 'key' pointer (0xd104) 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
Re: Bug#653653: nbd: FTBFS on sparc: Bus error (core dumped) - FAIL: integrity
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 (0xd104) 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
Re: Bug#653653: nbd: FTBFS on sparc: Bus error (core dumped) - FAIL: integrity
Where can I read the source for nbd-tester-client.c? I just did a quick scan of ghash.c but I didn't see anything really silly going on, so I'd like to check this file. All copies I can find of nbd-tester-client.c seem to be short (600 lines) and not use glib at all. Patrick On Sat, Mar 3, 2012 at 3:03 AM, Jurij Smakov ju...@wooyd.org wrote: On Fri, Mar 02, 2012 at 12:52:33AM +0100, Julien Cristau wrote: cc+=debian-sparc@ On Wed, Feb 29, 2012 at 14:14:46 +0100, Wouter Verhelst wrote: tags 653653 + help thanks On Fri, Dec 30, 2011 at 12:40:09AM +0100, Jakub Wilk wrote: Source: nbd Version: 1:2.9.25-2 Severity: serious Justification: fails to build from source User: debian-sparc@lists.debian.org Usertags: sparc nbd FTBFS on sparc: | ./integrity | 28870: Seq 0002 Queued: 0001 Inflight: Done: | Bus error (core dumped) | FAIL: integrity Full build log: https://buildd.debian.org/status/fetch.php?pkg=nbdarch=sparcver=1%3A2.9.25-2stamp=1325194394 So, I had a look at this on the porter machines a while back, and I have to say I'm a bit stumped as to what's wrong. There's some stack corruption going on inside nbd-tester-client (the test suite client that tests whether nbd-server runs correctly), which makes things a bit harder; but I can't see why there should be any such stack corruption. Running this inside valgrind (on amd64) also doesn't flag anything suspicious. Help from anyone familiar with SPARC would be appreciated. Here's a backtrace: Program received signal SIGBUS, Bus error. 0xf7f49c08 in g_int64_equal (v1=0x2bd28, v2=0xd104) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/gutils.c:3567 3567 /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/gutils.c: No such file or directory. (gdb) bt #0 0xf7f49c08 in g_int64_equal (v1=0x2bd28, v2=0xd104) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/gutils.c:3567 #1 0xf7ef529c in g_hash_table_lookup_node (hash_return=synthetic pointer, key=0xd104, hash_table=0x2b000) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/ghash.c:381 #2 g_hash_table_lookup (hash_table=0x2b000, key=0xd104) at /build/buildd-glib2.0_2.30.2-6-sparc-t4y8Aw/glib2.0-2.30.2/./glib/ghash.c:1029 #3 0x00014580 in integrity_test (hostname=optimized out, port=optimized out, name=optimized out, sock=7, sock_is_open=optimized out, close_sock=optimized out, testflags=0) at nbd-tester-client.c:1103 #4 0x00010f98 in main (argc=7, argv=0xd254) at nbd-tester-client.c:1309 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: GHashTable *handlehash = g_hash_table_new(g_int64_hash, g_int64_equal); The 'key' pointer (0xd104) 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
Re: Bug#653653: nbd: FTBFS on sparc: Bus error (core dumped) - FAIL: integrity
On Sat, Mar 3, 2012 at 09:55:51 -0600, Patrick Baggett wrote:
Where can I read the source for nbd-tester-client.c? I just did a quick
scan of ghash.c but I didn't see anything really silly going on, so I'd
like to check this file. All copies I can find of nbd-tester-client.c
seem to be short (600 lines) and not use glib at all.
It does this:
/*
* This is the reply packet that nbd-server sends back to the client after
* it has completed an I/O request (or an error occurs).
*/
struct nbd_reply {
__be32 magic;
__be32 error; /* 0 = ok, else error */
char handle[8]; /* handle you got from request */
};
[...]
GHashTable *handlehash = g_hash_table_new(g_int64_hash, g_int64_equal);
struct nbd_reply rep;
READ_ALL_ERRCHK(sock,
rep,
sizeof(struct nbd_reply),
err_open,
Could not read from server socket: %s,
strerror(errno));
[...]
prc = g_hash_table_lookup(handlehash, rep.handle);
So alignof(struct nbd_reply) is 4, and rep.handle is not always 8-byte
aligned. Either the handle should be made a uint64_t, or the test
should do
uint64_t handle;
memcpy(handle, rep.handle, 8);
prc = g_hash_table_lookup(handlehash, handle);
Cheers,
Julien
signature.asc
Description: Digital signature
Unable to boot Debian Squeeze on Sun Blade 1500 Silver
Hi everyone, I have successfully installed Debian Squeeze on a Sun Blade 1500 Silver machine. But when I try to boot it from OpenBoot using the boot command, it does not boot. I have tried to run the recovery mode of the Debian Squeeze CD too, but to avail. Can anyone help me regarding this? I do not have any prior experience with UltraSPARC machines. Best Regards, Rigved Rakshit
