Let me start by saying, I'm not really sure V is at fault. I'm running V on Python 2.5 (version doesn't seem to matter, it probably affects all versions 2.3 and later). Python has a somewhat usual memory allocator so there are a bunch of reads/conditionals on uninitialized memory. This is not an issue. You can read more about it here: http://svn.python.org/projects/python/trunk/Misc/README.valgrind There *shouldn't* be any invalid reads though. I looked through the open bugs and didn't see anything that looked similar. I've run V 3.2.1 on gentoo on both x86 and amd64, both compiled from source. The strange thing is that all the addresses which are reported invalid end with the same value 0x4...010 on x86 and 0x5...020 on amd64. I will attach the full output of V for both platforms. The options probably don't matter, but: neal@python r25 $ echo $VALGRIND_OPTS --tool=memcheck --error-limit=no --trace-children=yes --leak-resolution=med --leak-check=yes --num-callers=15 ~/local/bin/valgrind -q --leak-check=no ./python -c pass I don't know how to make a small test case, but I can try to debug this if you can provide some guidance. I'd be happy to build V from src if you think this problem might have been fixed.
Created attachment 18452 [details] V output on amd64
Created attachment 18453 [details] V output on x86
I can't see any problem here, and certainly not any one in valgrind. It seems to me that the document you referred to explains exactly what is happening here and why it is not a problem. It also clearly explains how to build python to avoid the problem. There is nothing in that document to say that you should only get "conditional depends on" errors - indeed the example it quotes is not such an error. In any case you should probably talk to the python developers first - it is far more likely that you have found a problem in python than one in valgrind...