[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Reply to: