MADV_FREE and wait4 EFAULT

[Konstantin Belousov]

On Thu, Apr 18, 2013 at 02:51:43PM -0700, Carl Shapiro wrote:
> On Wed, Apr 17, 2013 at 1:21 AM, Konstantin Belousov <kostikbel at 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.
It would be of some interest to see the evidence.

Is your code multithreaded ?

> 
> 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.
The test case is required to decide whether the bug is in the application
or in the OS.

> 
> 
> > 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.
There is no difference in the access performed by copyout vs. access caused
by the usermode write.

> 
> 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.

No, I cannot give an advice, I think we should first decide which code
to blame.

BTW, you could try enabling sysctl machdep.uprintf_signal. Oh, you did not
specified the architecture and version of the system.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20130419/8c6babee/attachment.sig>