From owner-freebsd-hackers Thu Jun 3 22:46:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C370215156 for ; Thu, 3 Jun 1999 22:46:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA02924; Thu, 3 Jun 1999 22:35:03 -0700 (PDT) (envelope-from dillon) Date: Thu, 3 Jun 1999 22:35:03 -0700 (PDT) From: Matthew Dillon Message-Id: <199906040535.WAA02924@apollo.backplane.com> To: "David E. Cross" , freebsd-hackers@FreeBSD.ORG, schimken@cs.rpi.edu, crossd@cs.rpi.edu Subject: Re: 3.2-stable, panic #12 (simplified) References: <199906032057.QAA40503@cs.rpi.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I had the hunch that the problem I am dealing with related to the unlink :portion of NFS... So I have simplified the code down to this tiny snipet which :will reliably crash the system (I left it running by accident and it brought :my test machine down 3 times before I remembered to kill it :). This is only :3 lines of code, and a for loop to iterate it. : :int main(int argc, char **argv) :{ : int fd; : int counter; : char newfilename[1024]; : : strcpy(newfilename,argv[1]); : strcat(newfilename,".old"); : for(counter=0;counter<1000000;counter++) { : fd=open(argv[1], O_CREAT, 600); : close(fd); : unlink(argv[1]); : } : return 0; :} : :Again, this appears to need to be run from multiple machines at once to cause :the problem (running from 2 dual-ultra 2s running solaris 2.6 in this case). :I will attempt to reproduce it with FreeBSD clients later today. In the :meantime I am getting down and dirty with the NFS kernel routines. :... :-- :David Cross | email: crossd@cs.rpi.edu I think you said it was the server that crashed? Are you sure? I know for a fact that it is possible to crash a FreeBSD client when the server ( or another client ) renames-over or unlinks files rapidly that are also being accessed by the client. If it is the server crashing rather then the client we have a new bug. It should still hopefully be relatively easy to locate. Potential races in the server are much more confined ( in regards to areas of the code that might race ) then on the client. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message