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:
> 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: firstname.lastname@example.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.
#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)
#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.
Jurij Smakov email@example.com
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC