On Thu, Jun 3, 2010 at 6:19 PM, Jason Evans <[email protected]> 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 _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
