On Tue, 2016-08-30 at 10:02 -0700, Mark Roberts wrote: > 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? Difficult to say, as I do not know what your tool exactly does. However, here are a few remarks: It is not very clear why a 'is_valid_for_valgrind' would be appropriate for a tool to decide to dereference a 'guest pointer'. A guest (client) pointer should only point to guest memory. If it points to valgrind memory, this cannot be a valid guest pointer, and should not be dereferenced. Another remark is related to the use of 'is_mem_defined' : this will be False if the data is partially defined. I am wondering what is the desired behaviour for your tool for partially defined variables. For sure, valid C/C++ code can have partially defined bytes. For memcheck leak search, pointers must be fully defined. But that is very specific to leak search. Finally, I still wonder how you can have memory which is defined but that you cannot read without having a SEGV. As discussed earlier, something very strange must have happened to achieve such a state. Hoping this helps Philippe ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
