From owner-freebsd-bugs  Tue May 11 10:41:43 1999
Delivered-To: freebsd-bugs@freebsd.org
Received: from luke.pmr.com (luke.pmr.com [207.170.114.132])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6DC0C15A4C; Tue, 11 May 1999 10:41:26 -0700 (PDT)
	(envelope-from bob@luke.pmr.com)
Received: (from bob@localhost)
	by luke.pmr.com (8.9.3/8.9.2) id MAA28921;
	Tue, 11 May 1999 12:41:17 -0500 (CDT)
	(envelope-from bob)
Date: Tue, 11 May 1999 12:41:17 -0500
From: Bob Willcox <bob@luke.pmr.com>
To: Pierre Beyssac <beyssac@enst.fr>
Cc: freebsd-bugs@freebsd.org, bob@pmr.com,
	FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/10872: Panic in sorecieve()
Message-ID: <19990511124117.A28606@luke.pmr.com>
Reply-To: Bob Willcox <bob@pmr.com>
References: <19990511185956.A12679@enst.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.1i
In-Reply-To: <19990511185956.A12679@enst.fr>; from Pierre Beyssac on Tue, May 11, 1999 at 06:59:56PM +0200
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Tue, May 11, 1999 at 06:59:56PM +0200, Pierre Beyssac wrote:
> I was looking into PR kern/10872, hoping to find an easily fixable
> occurence of NULL mbuf pointer. But it doesn't seem to be.
> 
> It's labelled "Panic in sorecieve() due to NULL mbuf pointer", but
> from the debug data filed with the PR it seems the actual problem
> is with so_rcv.sb_cc being 0, which triggers a KASSERT in uipc_socket.c:
> 
>         if (m == 0 || (((flags & MSG_DONTWAIT) == 0 &&
>             so->so_rcv.sb_cc < uio->uio_resid) &&
>             (so->so_rcv.sb_cc < so->so_rcv.sb_lowat ||
>             ((flags & MSG_WAITALL) && uio->uio_resid <= so->so_rcv.sb_hiwat)) &&
>             m->m_nextpkt == 0 && (pr->pr_flags & PR_ATOMIC) == 0)) {
>                 KASSERT(m != 0 || !so->so_rcv.sb_cc, ("receive 1"));
> 
> (more data can be found in the PR)

Hmm, I haven't looked at this in a few weeks (I downgraded my amanda
backup server to 2.2.8 to work around the problem till I could find a
fix).  The problem as I have seen it is that the mbuf chain pointer (m)
is NULL and so_rcv.sb_cc is not zero.  Its as though somewhere either
the mbuf chain pointer gets zapped with NULL or something fails to
properly update so_rcv.sb_cc as mbufs are processed.

I believe one can expand the KASSERT macro and rewrite the line:

    KASSERT(m != 0 || !so->so_rcv.sb_cc, ("receive 1"));

as

    do {
	if (!(m != 0 || !so->so_rcv.sb_cc))
	    panic("receive 1");
    } while (0);

which can be simplified into:

    do {
	if (m == 0 && so->so_rcv.sb_cc != 0)
	    panic("receive 1");
    } while (0);

by removing the ! from the expression and adjusting it accordingly.

> 
> I can't seem to be able to reproduce the problem on -current with
> the script provided by Bob, and I don't have a -stable box to try
> it on either.

I have been able to reproduce it on both -stable and -current (but not
2.2.8).  I have a full-duplex 100Mb ethernet switch that my systems
are on.  On slower networks it may not fail.  It seems to be timing
dependent.

> 
> Plus, I don't have (yet) much of a clue regarding the semantics of
> sb_cc. I continue investigating this stuff, but if anyone has more
> clue than I have, he's welcome to send me some directions to look
> into :-)
> -- 
> Pierre Beyssac		pb@enst.fr

-- 
Bob Willcox             The man who follows the crowd will usually get no
bob@luke.pmr.com        further than the crowd.  The man who walks alone is
Austin, TX              likely to find himself in places no one has ever
                        been.            -- Alan Ashley-Pitt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message