Re: port-amd64/43236: Removing a file while it is accessed through NFS crashes the server

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/43236; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-amd64/43236: Removing a file while it is accessed through
        NFS crashes the server
Date: Mon, 3 May 2010 05:35:46 +0000

 On Mon, May 03, 2010 at 05:20:03AM +0000, Peter Kerwien wrote:
  >>  (From your description, it sounds like the count thing was it making a
  >>  crash dump. Pity it apparently didn't succeed.)
  >  
  >  How do I know if it succeeds or not (I'm a NetBSD debug-n00b)?
 
 Well, if it hangs, it probably didn't succeed. But that depends on
 where it hung... after a successful dump, provided everything works
 the way it's supposed to, you'll get the dump saved to /var/crash on
 the next boot. At that point you can use a debugger or various system
 tools on it.
 
 You can also turn on the built-in debugger by doing
 
    sysctl -w ddb.onpanic=1
 
 (assuming it's compiled into the kernel; it is by default, otherwise
 uncomment "options DDB") and you can then get a stack backtrace from
 it by typing "bt". The important stuff is the panic message (and any
 other messages it may print right before) and, probably, the first few
 lines of the backtrace.
 
 If you end up compiling a kernel to test this, turning on DIAGNOSTIC
 and/or LOCKDEBUG may be helpful too. Note that LOCKDEBUG is really
 slow though...
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost