From owner-freebsd-current@FreeBSD.ORG Thu Nov 27 08:30:30 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 CFCA716A4CE; Thu, 27 Nov 2003 08:30:30 -0800 (PST) Received: from Vitsch.net (b74143.upc-b.chello.nl [212.83.74.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03A7043FAF; Thu, 27 Nov 2003 08:30:28 -0800 (PST) (envelope-from Danovitsch@Vitsch.net) Received: from FreeBSD.Danovitsch.LAN (b83007.upc-b.chello.nl [212.83.83.7]) by Vitsch.net (8.12.3p2/8.11.3) with ESMTP id hARGUDXe011375; Thu, 27 Nov 2003 17:30:13 +0100 (CET) (envelope-from Danovitsch@Vitsch.net) Content-Type: text/plain; charset="iso-8859-1" From: "Daan Vreeken [PA4DAN]" To: Jay Cornwall Date: Thu, 27 Nov 2003 17:30:59 +0100 User-Agent: KMail/1.4.3 References: <1069874342.704.18.camel@klotz.local> <200311270856.44214.Danovitsch@Vitsch.net> <3FC60B3B.2000403@evilrealms.net> In-Reply-To: <3FC60B3B.2000403@evilrealms.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200311271730.59498.Danovitsch@Vitsch.net> cc: FreeBSD-current@FreeBSD.org cc: imp@FreeBSD.org Subject: Re: Panic with ugen 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: Thu, 27 Nov 2003 16:30:30 -0000 On Thursday 27 November 2003 15:33, Jay Cornwall wrote: > Daan Vreeken [PA4DAN] wrote: > > If you have time left, could you perhaps also have a look at kern/511= 86? > > I have filed it back in March and it's still open. (Fixes a memory > > corruption bug in ugen). > > I'm not a committer, I'm afraid, so it's probably best to get in touch = with > the code maintainer. (imp@freebsd.org, if the PR is correct - he did re= ply > at the bottom of the PR) > > But from a brief look at the code, I can't see anything getting past th= is > line: if(sce->fill < sce->cur && sce->cur <=3D sce->fill + count) > > If sce->fill is less than sce->cur, then sce->cur can only be <=3D (sce= ->fill > + count) if count is negative. But I haven't studied the code that clos= ely, > so maybe I'm just missing something obvious. :) It can. Imagine a buffer of 1000 bytes. sce->fill=3D980 and sce->cur=3D990. If we have to store 40 bytes, sce->fill (980) is smaller than sce->cur (9= 90). And sce->cur (990) is smaller or equal to sce->fill + count (980+40=3D102= 0). After that count gets added to sce->cur ( sce->cur=3D990+40=3D1030). Now sce->cur is bigger than sce->limit so this line of code get execute : sce->cur =3D sce->ibuf + (sce->limit - sce->cur); Leading to : sce->cur =3D sce->ibuf + ( 1000 - 1030 ) =3D beginning-of-buffer - 30 ! In stead of : sce->cur =3D sce->ibuf + ( 1030 - 1000 ) =3D beginning-of-buffer + 30 grtz, Daan