From owner-freebsd-current@FreeBSD.ORG Mon Aug 25 04:14:05 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 887D016A4BF for ; Mon, 25 Aug 2003 04:14:05 -0700 (PDT) Received: from sweeper.openet-telecom.com (mail.openet-telecom.com [62.17.151.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9356C43F93 for ; Mon, 25 Aug 2003 04:14:01 -0700 (PDT) (envelope-from peter.edwards@openet-telecom.com) Received: from mail.openet-telecom.com (unverified) by sweeper.openet-telecom.com ; Mon, 25 Aug 2003 12:17:19 +0100 Received: from [10.0.0.40] (10.0.0.40) by mail.openet-telecom.com (NPlex 6.5.027) id 3F3CF2360000586E; Mon, 25 Aug 2003 12:11:50 +0100 From: Peter Edwards To: Yogeshwar Shenoy In-Reply-To: References: Content-Type: text/plain Organization: Openet Telecom Message-Id: <1061810038.714.79.camel@rocklobster.openet-telecom.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 25 Aug 2003 12:13:58 +0100 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: 5.1-R: zero byte core file. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2003 11:14:05 -0000 On Wed, 2003-08-20 at 22:11, Yogeshwar Shenoy wrote: > While using 5.1-RELEASE, I find that if my application program seg > faults, it produces "programname.core"; but it is 0 bytes. > I ran the exact same program on another machine that was running > 4.4-RELEASE, and I do get a core file that I can use with gdb. > I'd really appreciate if someone could help me resolve this. > > Additional details: > - It is not specific to the application program. I tried a 2 line program: > char p[8]; > memcpy(p, "1234567890123456789012345678901234567890", 40); > with same results on 5.1-R(0 byte core file) and 4.4-R(usable core file) > > - "ulimit -a" on the 5.1-R machine gives > core file size (blocks, -c) unlimited > > - Just to be sure I used getrlimit() to find what the limit for > RLIMIT_CORE is in my processes, and it is RLIM_INFINITY. > > - I did the basic checks like write permission on current directory, it > looks fine. > > Can someone help me resolve this? > > Thanks, > Yogeshwar. Hi, Is the core file been dumped to an NFS mount? If so, are you need to be running rpc.lockd or use the "-L" option for the NFS mount. Otherwise, you'll get the behaviour you've noticed. When dumping core, the kernel attempts to get an advisory lock on the corefile, to reduce the overhead in the pathological case where a large number of processes simultaneously start dumping core to the same file. There's a conflict between two default behaviours: rpc.lockd doesn't run by default (disabled in /etc/defaults/rc.conf), and NFS mounts try to use the service it provides unless you use the "-L" option. So, by default, advisory locking (and, by extension, core dumping) doesn't work on NFS mounts. The -stable branch doesn't do client-side NFS locking: It's advisory locking for NFS mounts "works", but is only visible to the local client. HTH, Peter.