|
From: Nicholas N. <nj...@cs...> - 2005-06-30 04:35:24
|
On Fri, 24 Jun 2005, Craig Chaney wrote: > 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. > > 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". Both these sound tricky; I can't see any obvious ways around them. N |