Date: Wed, 4 Feb 2004 12:41:11 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: frode@nordahl.net Cc: freebsd-current@FreeBSD.org Subject: Re: rpc.lockd(8) seg faults on 5.2-RELEASE Message-ID: <200402042041.i14KfB7E007199@gw.catspoiler.org> In-Reply-To: <C4DF668E-5717-11D8-B0FA-000A95A9A574@nordahl.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402042041.i14KfB7E007199>