Date: Fri, 19 Apr 2013 20:55:30 +0800 From: Julian Elischer <julian@freebsd.org> To: Carl Shapiro <carl.shapiro@gmail.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: MADV_FREE and wait4 EFAULT Message-ID: <51713EC2.4030401@freebsd.org> In-Reply-To: <CANVK_QgRBO5ZU=NHCr1XTvtxYpWk6LjWEv8Q-70mY6CzqHO2TA@mail.gmail.com> References: <CANVK_QgKRkpzWjA=H2u2HTp_vpxFhNLBGTVuFZmMEpBLTbzeaA@mail.gmail.com> <20130417082143.GW2930@kib.kiev.ua> <CANVK_QgRBO5ZU=NHCr1XTvtxYpWk6LjWEv8Q-70mY6CzqHO2TA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/19/13 5:51 AM, Carl Shapiro wrote: > On Wed, Apr 17, 2013 at 1:21 AM, Konstantin Belousov <kostikbel@gmail.com>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" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51713EC2.4030401>