From owner-freebsd-stable@FreeBSD.ORG Thu Jul 18 18:40:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C46E0B19 for ; Thu, 18 Jul 2013 18:40:53 +0000 (UTC) (envelope-from hartzell@alacrity.alerce.com) Received: from griffon.alerce.com (griffon.alerce.com [206.125.171.162]) by mx1.freebsd.org (Postfix) with ESMTP id B0161F4F for ; Thu, 18 Jul 2013 18:40:53 +0000 (UTC) Received: from griffon.alerce.com (localhost [127.0.0.1]) by griffon.alerce.com (Postfix) with ESMTP id 2AD212842A; Thu, 18 Jul 2013 11:40:53 -0700 (PDT) Received: from alacrity.alerce.com (75-149-38-78-SFBA.hfc.comcastbusiness.net [75.149.38.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by griffon.alerce.com (Postfix) with ESMTPSA id E4C4228424; Thu, 18 Jul 2013 11:40:52 -0700 (PDT) Received: by alacrity.alerce.com (Postfix, from userid 503) id E3D2E150C749; Thu, 18 Jul 2013 11:40:51 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20968.14003.813473.517439@gargle.gargle.HOWL> Date: Thu, 18 Jul 2013 11:40:51 -0700 To: Richard Todd Subject: Re: Help with filing a [maybe] ZFS/mmap bug. In-Reply-To: References: <20967.760.95825.310085@gargle.gargle.HOWL> X-Mailer: VM 8.2.0b under 24.2.1 (x86_64-apple-darwin) X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@freebsd.org, hartzell@alerce.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 18:40:53 -0000 Richard Todd writes: > George Hartzell writes: > > > Hi All, > > > > I have what I think is a ZFS related bug. > > [...] > > [summary: Picard seems to trigger an mmap consistency bug in ZFS]. > > [...] > Anyway, what I'd suggest is the following: see if my patch for py-mutagen > disabling the mmap() in those two functions lets you run picard reliably. Removing the mmap support from those two routines seems to avoid the issue. > If so, then the issue is triggered by one or both of those two routines; > hack them to print out the exact offsets used on each call and use that to > try and code up a simple C++ test case. > [...] Your test case doesn't use mmap, I assume that you've offered it up as a hint, not as something that's nearly done. The shell script in particular seems useful. In my case I'd want to find a particular set of file size, offset, and insertion size that triggers the problem and code up a c/c++ equiv. of the mmap calls that py-mutagen does. Right? I'm hesistant about that. I believe (and will try to prove) that the problem does not occur deterministically for a particular track between different test runs. I'm worried that it's not as simple as "using mmap to insert 27 bytes into a 1024 bytes file at pos 42 causes corruption" but rather that it depends on a more complex set of interactions. My next step will be to see if a track that has trouble in one run has trouble in another. If not, then I'm not sure that a simple test will be successful. g.