Coda File System

Re: venus crashes- what to look for in gdb/ coda wiki

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Thu, 1 Jul 2004 15:54:51 -0400
On Fri, Jun 25, 2004 at 03:09:03PM +0200, Gabriel Wicke wrote:
> Crash during bonnie testing:
>
> gdb where
> #0  0x401822a6 in sigsuspend () from /lib/tls/libc.so.6
> #1  0x080c8738 in SigChoke (sig=357693596) at sighand.cc:241
> #2  <signal handler called>
> #3  0x0807509e in fsobj::Open (this=0x75b67a48, writep=0, execp=0,
> truncp=0, cp=0x15521e18, uid=0) at fso.h:686

I've seen this backtrace before. It is unusual in the way that it looks
like it crashed in the 'IsDir' test. It looks like the object got pulled
out from under us even though we still had a reference count on it.

I guess your local cache held fewer files than were being used in the
bonnie dataset so there was replacement going on and some destructor
must be a bit too destructive.

The other crash you reported on the wiki (disconnected startup crash) is
something I hadn't seen before. It is somewhat clear what is going on.
Right after startup the fake /coda/ directory must be still empty and
instead of returning ENOENT the directory handling code decided that
this is unusual enough to trigger an assertion, I'll try to replace it
with returning ENOENT back up to the caller. The only thing that puzzles
me is why this doesn't happen every time we (re)start venus.

Jan
Received on 2004-07-01 15:56:49