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