On Tue, Sep 6, 2016 at 10:19 AM, Johannes Ziegenbalg < [email protected]> wrote:
> Hello everybody. > > While sampling with one of our tools I sometimes come across this bug. > If a sample is triggered, presumably while resolving a symbol of a > shared library, a SIGSEGV occurs. > > As libunwind is iterating up the stack, it checks if the address at #20 > (backtrace.txt) is accessible. But it's corresponding page is mapped > with the PROT_NONE property which is usually used for guard pages. > Since the memory is mapped correctly, calls to mincore() or msync() > succeed, stating that the address is valid. But what they don't test is > the actual accessibility of the address. > > Me and a colleague of mine are not sure if it's even a valid address or > a bug of some other library. I however attached a test case to > reproduce the error (access_mem_test.c) and a possible patch that adds > the necessary accessibility test. > This test uses write() to check if the value at an address can be > written to a pipe. If the address is not accessible the write fails but > doesn't raise a signal. > FWIW, we've also been checking write() rather than mincore() since 2009. > I'm certain, that the patch needs one or two more iterations e.g. the > pipe needs to be closed somewhere. Maybe you guys can help me out! > At a minimum, you probably want to set FD_CLOEXEC (or use pipe2(..., O_CLOEXEC)). If the forked process continues without execve, it will need to reopen the pipe, so our patch is quite a bit more involved. -- Paul Pluzhnikov
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
