On Sun, Jun 24, 2007 at 11:29:18PM +0930, Brett Lymn wrote:
> I am playing with coda on an amd64 machine running a fairly recent
> version of NetBSD-current (running 64bit for what it is worth).  The
> version of coda is 6.9.1 and was built from the NetBSD pkgsrc (though
> I had to tweak things to get it to build).  I set up coda and started

I'm interested to know which tweaks were needed.

> volume disappeared, venus was in a zombie state.  I rebuilt venus to
> include debug and when I attach with gdb a backtrace gives:
> 
> (gdb) bt
> #0  0x00007f7ffc92ff92 in _sys___sigsuspend14 () from /usr/lib/libc.so.12
> #1  0x0000000000462631 in SigChoke (sig=10) at sighand.cc:251
> #2  <signal handler called>
> #3  0x00000000004305dd in MarinerLog (
>     fmt=0x48d460 "cache::EndStatusWalk [%d]\n   [%d, %d, %d, %d] [%d, %d, %d] [%d, %d, %1.1f]%s") at mariner.cc:243
> #4  0x00000000004293b9 in hdb::StatusWalk (this=0x508f3710, vp=0x611600, 
>     TotalBytesToFetch=0x450a3f34, BytesFetched=<value optimized out>)
>     at hdb.cc:664

I think SIGBUS is typically an indication when we are trying to
dereference a pointer which is not correctly aligned (multiple of 8
bytes in the case of a 64-bit architecture).

When I tested the client and server on 64-bit I used an Intel cpu with
EM64T extensions and it could very well be that it may allow unaligned
pointers, or at least doesn't mind as much if they happen to be aligned
on a 4-byte boundary, or maybe I never actually got to this code path.

Looking at the MarinerLog function, it accepts a variable argument list
and tries to pass it on to vsnprintf. The variable argument list related
code in librpc2 (multi2.c) had quite a few issues in that area as well.

If you can start the client and then attach gdb, gdb will trap the bus
error before it is passed on to the application. I wonder if the problem
is with the call to MarinerLog, or with a call made from that function.

Jan