From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 20 10:07:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ED7C91A8 for ; Sat, 20 Apr 2013 10:07:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id A918915C9 for ; Sat, 20 Apr 2013 10:07:47 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-237-17.lns20.per1.internode.on.net [121.45.237.17]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r3JCtZPa035647 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Apr 2013 05:55:40 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51713EC2.4030401@freebsd.org> Date: Fri, 19 Apr 2013 20:55:30 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Carl Shapiro Subject: Re: MADV_FREE and wait4 EFAULT References: <20130417082143.GW2930@kib.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 10:07:48 -0000 On 4/19/13 5:51 AM, Carl Shapiro wrote: > On Wed, Apr 17, 2013 at 1:21 AM, Konstantin Belousov wrote: > >> Did you ensured with e.g. ktrace and procstat -v that your assumptions >> hold, i.e. the addresses supplied as wait4(2) arguments are valid ? >> Please provide the minimal test case demonstrating the behaviour. >> > Yes. I instrumented my code to check for a wait4 failure, print the > addresses of the status and rusage arguments, and dump the contents of > /proc/curproc/map. The addresses of the status and rusage arguments are > always in the range of a mapping and marked as read write. > > I have yet to distill the failure to a minimal test case. The test case I > do have is the test harness for the Go language. After running for about > 45 minutes I can observe a failure. I have been working to produce > something smaller and faster. > > >> MADV_FREE should only result in the possible lost of the previous >> content of the page, not in the faulting of the page access. From the >> inspection of the code, I do not see how MADV_FREE could result in >> the memory address becoming invalid. >> > I see. What has lead us to believe this might be an issue with page faults > is that writing zeroes to the page with memset before passing it to wait4 > makes the error go away. > > Do you have any advice about how one might go about instrumenting wait4 to > generate more information about a failed copyout? Are tools such as dtrace > useful in these situations or might it be too invasive? Because of the > protracted test cycle and my lack of knowledge in this area, conducting > experiments is quite painful at the moment. looks like a great example of something that dtrace should be able to help with. basically you can do a speculative dump of the stuff going on before the copyout and just store it in the case where the copyout fails. I'm just learning getting my dtrace training wheels but I think it may be able to give you what you need. > > Thanks, > > Carl > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >