|
From: Craig C. <cc...@us...> - 2005-06-24 13:47:24
|
Hi, As I've been looking into the last few remaining regression test failures for Paul's ppc port of Valgrind 2.4, I came across a couple of issues that I can't see an easy resolution for. The issues are minor and are not likely to have a very big impact on real-life valgrind use. But it would be nice to find a simple way to fix them. Issue 1: Sometimes, when the client program calls VALGRIND_DO_LEAK_CHECK, valgrind can miss some leaked memory blocks. This will happen when "dead" registers (i.e. registers that will never be read before being overwritten) still contain memory addresses of the blocks that are leaked. I found this with the leak-cycle and leak-tree regression tests. Since the memory walking algorithm includes all of the gprs in its root set, valgrind believes that there are live pointers to these blocks. I suppose it would be possible to find at least some of the "dead" registers by analyzing upcoming instructions. But that sounds like way too much complexity for something that is unlikely to occur in the real world. The leak-cycle and leak-tree tests are perhaps anomalous because they purposefully null out the pointer variables immediately before the call to VALGRIND_DO_LEAK_CHECK. Has this ever come up on x86? (Or perhaps with fewer registers it's less likely there.) Is there another way to handle this? Issue 2: The code that handles the cache for the dynamic loader (i.e. the code that mmap's /etc/ld.so.cache) frees the cache memory shortly before the client program's main() begins. The algorithm that operates on that cache utilizes a global pointer variable which points to addresses in the cache. That variable is left dangling when the cache is freed. Not really a bug, since it's never referenced again. But, the pointer happens to point to a memory area that gets reused later for mallocs (at least on ppc). This leads to minor inaccuracies when looking for leaked blocks. If you're really unlucky, the dangling ld pointer will point to the beginning of a leaked malloc block, causing the leak to go undetected. If you're only slightly unlucky, it will point to somewhere in the middle of a leaked memory block, causing valgrind to report the block as "possibly leaked" rather than "definitely leaked". So, not too big a deal, but something that might cause confusion. Is there an easy way to work around something like this? Thanks, Craig -- Craig Chaney cc...@us... |