Re: [Valgrind-users] memcheck question
We chase down pointers to find user values. Some of those pointers we modify to point to shadow memory (we copy chunks of the stack for safe keeping, for example) and I believe those Daikon allocated blocks are considered Valgrind space not client space. Mark > -Original Message- > From: Julian Seward [mailto:jsew...@acm.org] > Sent: Tuesday, August 30, 2016 1:59 PM > To: Mark Roberts; 'Philippe Waroquiers' > Cc: valgrind-users@lists.sourceforge.net > Subject: Re: [Valgrind-users] memcheck question > > > I don't think that is_valid_for_valgrind should really be required. That > delimits areas which Valgrind itself can use but the client isn't allowed to > access. > > In what way is is_valid_for_client too strict? > > J -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] memcheck question
Ok - I was wrong. The problem is that is_valid_for_client is too strict. And or'ing that with is_valid_for_valgrind is too loose. In the end, by trial and error, I came with a test that seems to work for Daikon. First, I check the original is_mem_defined, if that fails, then we're done. If that passes, then check is_valid_for_client and is_valid_for_valgrind. If they are both zero then the address is bad, otherwise it's ok. Based on our tests, it looks like is_mem_defined does what I want, except it lets through references to user code pages. The two is_valid checks catch this case. So it seems I've fixed my problem - but I wonder if this technique makes sense to you? Thanks, Mark > -Original Message- > From: Mark Roberts [mailto:mar...@cs.washington.edu] > Sent: Tuesday, August 30, 2016 7:29 AM > To: 'Philippe Waroquiers' > Cc: 'valgrind-users@lists.sourceforge.net' > Subject: RE: [Valgrind-users] memcheck question > > Thank you, that is a big help. I do have a follow up question. When a > Valgrind client allocates memory that will be used as a shadow copy of the > user's data, I would guess that is not included in is_valid_for_client. As an > experiment, I ORd together the results of is_valid_for_cleint and > is_valid_for_valgrind and the results of running Daikon matched our previous > results - modulo now detecting reads from user space marked executable. > > Thanks, > Mark > > > > -Original Message- > > From: Philippe Waroquiers [mailto:philippe.waroqui...@skynet.be] > > Sent: Monday, August 29, 2016 1:52 PM > > To: Mark Roberts > > Cc: valgrind-users@lists.sourceforge.net > > Subject: Re: [Valgrind-users] memcheck question > > > > > > 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. > > -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] memcheck question
Thank you, that is a big help. I do have a follow up question. When a Valgrind client allocates memory that will be used as a shadow copy of the user's data, I would guess that is not included in is_valid_for_client. As an experiment, I ORd together the results of is_valid_for_cleint and is_valid_for_valgrind and the results of running Daikon matched our previous results - modulo now detecting reads from user space marked executable. Thanks, Mark > -Original Message- > From: Philippe Waroquiers [mailto:philippe.waroqui...@skynet.be] > Sent: Monday, August 29, 2016 1:52 PM > To: Mark Roberts > Cc: valgrind-users@lists.sourceforge.net > Subject: Re: [Valgrind-users] memcheck question > > > 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. > -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] memcheck question
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
Re: [Valgrind-users] memcheck 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? The *only* way to get a definitive answer is to attempt a write() from that address to a temporary file. If and only if you get no error, then the address is readable. You can read and decode /proc/self/maps, but even if a page has PROT_READ you might still get SIGBUS, such as when the page maps a hardware device which does not respond to the particular address. -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
