Re: [Libunwind-devel] mincore(2) problems on Linux

[Arun Sharma]

On Thu, Jun 3, 2010 at 6:19 PM, Jason Evans <address@hidden> wrote:
>
> I have been testing recent versions of libunwind on Centos 5.2 (x86_64), and 
> it appears that mincore(2) does not do what we want.  That is, msync(2) and 
> mincore(2) do not give the same results.

Neither one has the semantics that libunwind wants. libunwind wants to
know if there will be a SIGSEGV on dereferencing the pointer.

msync:

For PROT_NONE regions, the test succeeds. But if libunwind
dereferences the pointer, we get a SIGSEGV.

mincore:

For pages not currently in memory, validate_mem() fails even though it
was safe to dereference the pointer safely.

The "address crossing page boundary" problem is orthogonal to which
API is used and was not a reason in itself for accepting the patch
which switched the default to mincore on Linux.

Even if Linux implemented a validate_mem() system call which had the
exact semantics that libunwind wants, there may be race conditions
inherent in the API (Eg: another thread unmapping memory by the time
validate_mem() returns).

I'd be happy to take a patch to msync() that addresses the page
crossing problem and reconsider the choice between mincore vs msync if
there is a good test case to show one is better than the other.

If the system call returns an error, we could just return a NULL stack
trace instead of doing more drastic things (just to preserve the
popularity of profilers and tools using libunwind :)

 -Arun