From owner-freebsd-bugs Thu Apr 18 3:50:31 2002 Delivered-To: freebsd-bugs@freebsd.org Received: from hpux38.dc.engr.scu.edu (hpux38.dc.engr.scu.edu [129.210.16.38]) by hub.freebsd.org (Postfix) with ESMTP id A385737B416 for ; Thu, 18 Apr 2002 03:50:13 -0700 (PDT) Received: from localhost (dclark@localhost) by hpux38.dc.engr.scu.edu (8.10.2/8.10.2) with ESMTP id g3HHVvf02151 for ; Wed, 17 Apr 2002 10:31:57 -0700 (PDT) Date: Wed, 17 Apr 2002 10:31:56 -0700 (PDT) From: "Dorr H. Clark" To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/36504: crash/panic vm_object_allocate under file system code w/fix In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 2 Apr 2002, Matt Dillon wrote: > Second problem: vm_object_allocate() assumes that the zalloc() > will succeed. The system must be crashing in there, before > your defensive check. Mr. Dillon, you are right about that. I had an incomplete back trace that someone else wrote down, and they missed the top symbol. I added the following diff to the PR to cover this oversight: --- /usr/src/sys/vm/vm_object.c Fri Aug 4 15:31:11 2000 +++ ./vm_object.c Tue Apr 9 20:44:39 2002 @@ -223,9 +223,8 @@ { vm_object_t result; - result = (vm_object_t) zalloc(obj_zone); - - _vm_object_allocate(type, size, result); + if ((result = (vm_object_t) zalloc(obj_zone))) + _vm_object_allocate(type, size, result); return (result); } The back trace that occurs WITHOUT this change is here: _vm_object_allocate+d(2,0,0) vm_object_allocate+24 vnode_pager_alloc+b1 vop_stdcreatevobject+d4 vop_defaultop+15 ufs_vnoperate+15 vfs_object_create+32 vn_open+14b open+b8 syscall2+1f1 > Ok, I've looke at this some more. The second part of the patch > created a little confusion I'm sorry about the grody patch, I hadn't used the bug system before and I started talking to it from a HPUX system. I've submitted a better diff (i.e.- from FreeBSD) with a slightly different change to vfs_default.c but the same idea. > The only thing that can cause vm_object_allocate() > to fail that I know of is if the system runs out of KVM. I'm just running 4.4, I'm not familiar with -current, but I thought the zone gets it's own KVM range when initialized. Then if the free items on the zone drops below the low-water mark it tries to malloc inside of _zget(), so it can get handed a NULL back if the pages are gone. I believe the crash point is indeed in _vm_object_allocate() when it dereferences the NULL, the other two files are just changing to propagate the NULL tolerance back up the calling chain. So I thought your comment in the PR about low pages was right. I believe running out of KVM is only a condition that would occur on bootup. > What you need to do if you are experiencing crashes is to compile up a > debug kernel and obtain a crash dump. I should be able to diagnose > the cause of the crash from that. OK, will try to do, but it's rare. Also, as you may know, savecore is busted in 4.4, so the core files are not readable. I understand the problem (savecore's trying to seek on a pipe) but I'm having a little trouble back-porting the fix. Thanks for your attention to this problem. -dhc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message