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-sp...@lists.debian.org > > > Usertags: sparc > > > > > > nbd FTBFS on sparc: > > > | ./integrity > > > | 28870: Seq 00000002 Queued: 00000001 Inflight: 00000000 Done: 00000000 > > > | Bus error (core dumped) > > > | FAIL: integrity > > > > > > Full build log: > > > https://buildd.debian.org/status/fetch.php?pkg=nbd&arch=sparc&ver=1%3A2.9.25-2&stamp=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=0xffffd104) 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=0xffffd104) 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=0xffffd104, 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=0xffffd104) 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=0xffffd254) 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 (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-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org