MADV_FREE and wait4 EFAULT

[Julian Elischer]

On 4/19/13 5:51 AM, 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.
>
> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>
>