Re: Bug#653653: nbd: FTBFS on sparc: Bus error (core dumped) - FAIL: integrity
There are some other problems too:
makebuf() [ln 701] does this:
uint64_t* p = (uint64_t*)buf;
in this, buf is a char*. This violates the strict aliasing rules that say a
char* may alias any type, but not the other way around: uint64_t* may not
alias a char*. The difference is subtle: modifying buf[] will cause a
reload of p[] values, but modifying p[] will not cause a reload of buf[].
Though a violation, it is probably safe since only one is accessed in this
scope.
Also, checkbuf() [ln 717] does this:
char cmp[512];
makebuf(cmp, seq, blknum);
This means 'cmp' is going to be reinterpreted as a uint64_t in makebuf() --
but the char[] base type does guarantee 8-byte alignment, so this may or
may not fail. It should probably be declared as:
uint64_t cmp[64]; // 512/8 = 64
makebuf((char*)cmp, seq, blknum);
Changing the protoype of makebuf() to take uint64_t may be appropriate as
well since it seems to be called in that context.
Patrick
On Sat, Mar 3, 2012 at 10:11 AM, Julien Cristau wrote:
> 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
>
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
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 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=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=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= 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=, > port=, name=, sock=7, sock_is_open= out>, >close_sock=, 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
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=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=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=, 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=, port=, name=, sock=7, sock_is_open=, close_sock=, 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
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=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. > signature.asc Description: Digital signature
