Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Apr 2013 11:53:22 -0700
From:      Carl Shapiro <carl.shapiro@gmail.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: MADV_FREE and wait4 EFAULT
Message-ID:  <CANVK_Qjsa8-%2BtELi--Z6QttxhbkzxTQ1_aGyz=BGcYh3ng2qfw@mail.gmail.com>
In-Reply-To: <20130419124942.GA67273@kib.kiev.ua>
References:  <CANVK_QgKRkpzWjA=H2u2HTp_vpxFhNLBGTVuFZmMEpBLTbzeaA@mail.gmail.com> <20130417082143.GW2930@kib.kiev.ua> <CANVK_QgRBO5ZU=NHCr1XTvtxYpWk6LjWEv8Q-70mY6CzqHO2TA@mail.gmail.com> <20130419124942.GA67273@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 19, 2013 at 5:49 AM, Konstantin Belousov <kostikbel@gmail.com>wrote:

> It would be of some interest to see the evidence.
>

Certainly.  Here is some of the debugging messages that I added to my
application.  The first line is a print statement that executes after the
system call returns.  (As an aside, we issue system calls directly and do
not link against the C library.)  The other 2 lines of interest are output
from the dump of /proc/curproc/map that correspond to the status and rusage
addresses.

wait4 returned EFAULT, status is 0xc20021c0e8 rusage is 0xc2000eaf30
...
0xc1ffff0000 0xc200100000 245 0 0xfffffe07cd9ebbc8 rw- 1 0 0x3000 COW NNC
default - CH 1001
...
0xc200200000 0xc200300000 250 0 0xfffffe0215e3ed98 rw- 1 0 0x3000 COW NNC
default - CH 1001

I realize this might not be satisfying but I am happy to provide any other
information you might be interested in.

Is your code multithreaded ?
>

Yes.

The test case is required to decide whether the bug is in the application
> or in the OS.
>

To be clear, I do not have a strong reason to believe there bug is in
FreeBSD.  My original enquiry was solely into whether we were misusing
MADV_FREE pages.  However, the wait4 failure is very suspicious because the
only two addresses written to are "out" parameters.


>  There is no difference in the access performed by copyout vs. access
> caused
> by the usermode write.
>

Thanks.


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

Well, I have a strong suspicion the problem is caused by my application for
the reasons mentioned above.


> BTW, you could try enabling sysctl machdep.uprintf_signal.


This does not seem to be available in my kernel but I could patch this
change...

http://svnweb.freebsd.org/base/head/sys/amd64/amd64/trap.c?r1=239251&r2=239252&;

...and it looks like I need to rebuild my kernel anyway to enable DTrace.


> Oh, you did not
> specified the architecture and version of the system.


Sorry, here is what "uname -mv" says

FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012
root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANVK_Qjsa8-%2BtELi--Z6QttxhbkzxTQ1_aGyz=BGcYh3ng2qfw>