On Mon, 2016-08-29 at 07:28 -0700, Mark Roberts wrote: > The C/C++ front end to our tool Daikon includes most of Valgrind’s > memcheck code. We monitor the execution of a user’s program and > record the values seen for various program variables. As we follow > pointer variables, we need to make sure they point to valid memory > before we attempt to read the contents. We have seen very > intermittent failures in the code, but I think I have finally got a > repeatable one. Now to my question. > > > > We are using “is_mem_defined” (in mc_main.) to test for “is it safe to > read this location?” and that does not appear to be quite right. It > looks as though an address in a code segment is defined, but not > readable. We get a SIGSEGV with a bad permissions message when we > try. Whether or not that is the correct analysis is not as important > as the primary question: > > > > What is the proper way to check to see if an address is readable? > And, similarly, is writable?
Memcheck VA bits are only maintaining addressibility and, when addressable the definedness. The memcheck bits do not allow to make the distinction based on protection (r and/or w and/or x). Checking the protection can be done with VG_(am_is_valid_for_client). This check is implemented by the address space manager, that maintains the address space segments and protections. However, in case very strange things/bugs are done by the application, possibly, the address space manager state is desynchronised from the real state. You might be interested to read mc_leakcheck.c heuristic and memory scan, that are protecting themselves against dereferencing 'invalid pointers'. You might also read the test memcheck/tests/leak-segv-jmp.c which verifies the behaviour when such strange things happens. Philippe ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
