From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 02:22:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C457B106566B for ; Fri, 17 Apr 2009 02:22:15 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8019F8FC24 for ; Fri, 17 Apr 2009 02:22:15 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so440271yxm.13 for ; Thu, 16 Apr 2009 19:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=YFhx5AzRInjdmCVENtTpWbHj8bvRbg5BqpRqGFkLOPA=; b=OuOe1qeL08qB8gr3agcjkWo/x7PmqH6zN19Pg3vso6bkkO3DiHO11SRfXQ4kP+vW5E n63YfYmjOFZ5uMnicYbx2xT1kNyOzHatwSvhNYtQtJ0IiCwcj5lQur7N7HPJnBqGCxdq meC6dOaCTXvsvrnDwHCYcwBevbvlPfHTkZoHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Bs3RUtNjLgtDjf4XNXiCGwHyY5IKVp8FGUFzSnPSIEPZn3XyW0tdTvEQ6eFdpNIWF6 zG3ciz4jAH6rlbfx/8RrCZD66J72VKZyc1mDl856DEwtqYKvWtZp4IhlRnsXXNC2h7R1 68P5zxOThnnqj1TZyCh9C7H8rONC0PjodHSz0= MIME-Version: 1.0 Received: by 10.90.96.1 with SMTP id t1mr2498148agb.61.1239934934726; Thu, 16 Apr 2009 19:22:14 -0700 (PDT) Date: Thu, 16 Apr 2009 19:22:14 -0700 Message-ID: From: Maksim Yevmenkin To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best Subject: possible bug in the sbappendrecord_locked()? (Was: Re: core dump with bluetooth device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 17 Apr 2009 02:22:16 -0000 On Thu, Apr 16, 2009 at 5:39 PM, Maksim Yevmenkin wrote: > On Thu, Apr 16, 2009 at 12:59 PM, Alexander Best > wrote: >> hi there, >> >> i'm running r191076M. when i try to send files from my mobile phone to m= y >> computer via bt the core dumps. here's a backtrace: >> >> Unread portion of the kernel message buffer: >> sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 >> packet tree: >> =A0 =A0 =A0 =A00xc8d54d00 >> panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 >> cpuid =3D 0 > > are you, by change, have "options =A0SOCKBUF_DEBUG" in your kernel? ok, there is something strange going on in the sbappendrecord_locked(). consider the following initial conditions: 1) sockbuf sb is empty, i.e. sb_mb =3D=3D sb_mbtail =3D=3D sb_lastrecord = =3D=3D NULL 2) sbappendrecord_locked() is given mbuf m0 with has exactly one mbuf, i.e. m0->m_next =3D=3D NULL so void sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0) { struct mbuf *m; SOCKBUF_LOCK_ASSERT(sb); if (m0 =3D=3D 0) return; m =3D sb->sb_mb; if (m) while (m->m_nextpkt) m =3D m->m_nextpkt; --> m is still NULL at this point /* * Put the first mbuf on the queue. Note this permits zero length * records. */ sballoc(sb, m0); SBLASTRECORDCHK(sb); --> passed successfully, because sb_mb =3D=3D sb_lastrecord =3D=3D NULL (i.= e. sockbuf is empty) SBLINKRECORD(sb, m0); --> at this point sb_mb =3D=3D sb_lastrecord =3D=3D m0, _but_ sb_mtail =3D= =3D NULL if (m) m->m_nextpkt =3D m0; else sb->sb_mb =3D m0; --> not sure about those lines above, didn't SBLINKRECORD(sb, m0) take care of it already? --> in any case, still, sb_mb =3D=3D sb_lastrecord =3D=3D m0 _and_ still sb_mtail =3D=3D NULL m =3D m0->m_next; m0->m_next =3D 0; --> m is still NULL here if (m && (m0->m_flags & M_EOR)) { m0->m_flags &=3D ~M_EOR; m->m_flags |=3D M_EOR; } --> sbcompress() is called with m =3D=3D NULL, which is triggers the panic (read below) sbcompress(sb, m, m0); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D void sbcompress(struct sockbuf *sb, struct mbuf *m, struct mbuf *n) { int eor =3D 0; struct mbuf *o; SOCKBUF_LOCK_ASSERT(sb); while (m) { --> lots of code that never gets executed because m =3D=3D NULL } if (eor) { KASSERT(n !=3D NULL, ("sbcompress: eor && n =3D=3D NULL")); n->m_flags |=3D eor; } --> this where panic happens, because sb_mbtail is still NULL, but sockbuf now contains exactly one record SBLASTMBUFCHK(sb); } so, it looks like, sbcompress() should only be called when m !=3D NULL. also, when m =3D=3D NULL, m0 should be marked as EOR. comments anyone? thanks, max