MADV_FREE and wait4 EFAULT

[Carl Shapiro]

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.

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.

Thanks,

Carl