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-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-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 > >
