On 4/19/13 5:51 AM, Carl Shapiro wrote:
On Wed, Apr 17, 2013 at 1:21 AM, Konstantin Belousov <kostik...@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-unsubscr...@freebsd.org"
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
