|
From: Ashley P. <api...@co...> - 2008-08-01 11:18:32
|
On Fri, 2008-08-01 at 14:07 +0300, Yeshurun, Meir wrote: > Hi, > > I'd like to share with you the reason Valgrind could not reproduce the > memory violation we had. The faulty module was making decisions based > on > block addresses, and the corruption only occurred when those addresses > satisfied certain conditions (it's actually a very well-written module > except for this bug). > I believe this is the most common reason for cases where memory > corruptions are not reproduced when running Valgrind. It's only the second time I've ever heard of such a bug, the previous time was when porting code to ia64 and the code was doing a < on a stack and heap address, on ia64 these two are in the other order to i386. It's a fairly rare bug. > So is there any chance Valgrind could ever be enhanced to maintain > variable and heap block addresses so they match the addresses of a > native run? You'll find the native addresses you get vary not only from system to system but also from run to run on the same system, what you ask for is would not only be highly difficult I'm not sure it would be of value. What might be interesting is knowing which memory locations contained pointers and reporting errors if they are ever used in comparisons, I suspect there are legitimate reasons for doing this that i haven't thought of however so I'd expect the false-positive rate would be quite high. Ashley Pittman. |