On Wed, May 25, 2005 at 10:27:16AM -0600, Patrick Walsh wrote:
> #0  0xb73f99d6 in __sigsuspend (set=0x1532f0bc)
>     at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
> #1  0x080ab4f5 in strcpy () at ../sysdeps/generic/strcpy.c:31
/tmp/buildd/coda-6.0.10/coda-src/venus/worker.cc:403

> #2  <signal handler called>
> #3  0x080c99a2 in strcpy () at ../sysdeps/generic/strcpy.c:31
htonvv(ViceVersionVector *, ViceVersionVector *)
/tmp/buildd/coda-6.0.10/coda-src/vv/nettohost.cc:102

> #4  0x1532f480 in ?? ()
		In some shared library?

> #5  0x0804e559 in strcpy () at ../sysdeps/generic/strcpy.c:31
conn_iterator::conn_iterator(ConnKey *)
/tmp/buildd/coda-6.0.10/coda-src/venus/comm.cc:429

> #6  0x080ac46c in strcpy () at ../sysdeps/generic/strcpy.c:31
worker::main(void)
/tmp/buildd/coda-6.0.10/coda-src/venus/worker.cc:1151

> #7  0x080ac14c in strcpy () at ../sysdeps/generic/strcpy.c:31
worker::AwaitRequest(void)
/tmp/buildd/coda-6.0.10/coda-src/venus/worker.cc:1050

The rest of the trace didn't seem to make any sense at all, it was
jumping from repvol::GetVolAttr, vproc::symlink, vproc::do_ioctl,
vproc::namev, to WorkerMux.

So I'm not sure whether these make any sense, but it definitely looks
like there is a corruption in a list of connection entries. Now to read
some source...

Jan