From owner-freebsd-current@FreeBSD.ORG  Wed Feb  4 12:41:32 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 A10FD16A4CE
	for <freebsd-current@FreeBSD.org>;
	Wed,  4 Feb 2004 12:41:32 -0800 (PST)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 97A9243D2F
	for <freebsd-current@FreeBSD.org>;
	Wed,  4 Feb 2004 12:41:29 -0800 (PST)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i14KfB7E007199;
	Wed, 4 Feb 2004 12:41:16 -0800 (PST)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200402042041.i14KfB7E007199@gw.catspoiler.org>
Date: Wed, 4 Feb 2004 12:41:11 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
To: frode@nordahl.net
In-Reply-To: <C4DF668E-5717-11D8-B0FA-000A95A9A574@nordahl.net>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
cc: bsder@allcaps.org
cc: freebsd-current@FreeBSD.org
Subject: Re: rpc.lockd(8) seg faults on 5.2-RELEASE
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2004 20:41:32 -0000

On  4 Feb, Frode Nordahl wrote:
> 
> On Feb 3, 2004, at 12:06, Don Lewis wrote:
>>
>> Probably not a NULL pointer because &ifl->filehandle will be the same
>> value as (char *)ifl+offsetof(struct file_lock, filehandle), and
>> LIST_FOREACH() will bail out when ifl is NULL.  It would be interesting
>> to walk the lock list starting at nfslocklist_head and following the
>> nfslocklist links so see if any of the link values look bogus.
> 
> hum, on my last core dump, nfslocklist_head->lh_first->le_next and 
> le_prev are uninitialized pointers.
> 
> Other dumps have other results though, I'll look more into it tonight.
> 
> (using malloc.conf -> J)
> 
> (gdb) print *nfslocklist_head->lh_first
> $3 = {nfslocklist = {le_next = 0xd0d0d0d0, le_prev = 0xd0d0d0d0},
>    filehandle = {fh_fsid = {val = {-791621424, -791621424}}, fh_fid = {
>        fid_len = 53456, fid_reserved = 53456,
>        fid_data = '?' <repeats 16 times>}}, addr = 0xd0d0d0d0, client = {
>      exclusive = -791621424, svid = 3503345872, oh = {n_len = 3503345872,
>        n_bytes = 0xd0d0d0d0 <Address 0xd0d0d0d0 out of bounds>},
>      l_offset = 15046755950319947984, l_len = 15046755950319947984},
>    client_cookie = {n_len = 3503345872,
>      n_bytes = 0xd0d0d0d0 <Address 0xd0d0d0d0 out of bounds>},
>    client_name = '?' <repeats 1024 times>, nsm_status = -791621424,
>    status = -791621424, flags = -791621424, blocking = -791621424,
>    locker = -791621424, fd = -791621424}

Since allocate_file_lock() bzero's the entire file_lock structure,
including le_next and le_prev, and since the everything in this
structure appears to be initialized to 0xd0d0d0d0, it looks like
nfslocklist is pointing to something on the free list.  Probably
something is calling deallocate_file_lock() without first removing the
lock from the list.