MADV_FREE and wait4 EFAULT

[Konstantin Belousov]

On Fri, Apr 19, 2013 at 11:53:22AM -0700, Carl Shapiro wrote:
> On Fri, Apr 19, 2013 at 5:49 AM, Konstantin Belousov <kostikbel at 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.
Just observations/speculations:

the addresses you shown are not the (usual) addresses for the malloc heap
on amd64. It is possible to allocate and map enough shared libraries to
make malloc start using these addresses, but more likely your app is
using custom mmap() calls, possibly with the explicite address hints or
MAP_FIXED. Am I right ?

If yes and your app is multithreaded, it is possible that other thread
performs some manipulations on the address space while current thread
tries to access the range.

> 
> 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.
In fact, the question is, why are you trying to access the memory after the
MADV_FREE. Was it correctly marked as 'still used' to prevent mmaps there ?

Note that all this is pure speculation.
-------------- 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/20130420/bedd4bf9/attachment.sig>