[Valgrind-users] Memcheck and lost pointer tracking

[Theodoros V. K. <th...@gm...>]

Hi,

I apologise beforehand if this has been discussed before, but in the list 
archives I only found a 2005 2-message thread that went nowhere. I do not 
have any experience with the Valgrind code, so if I sound ignorant it's 
probably because I am :-)

I just spent two days trying to find a memory leak, even with valgrind. 
The program (not my code, thank goodness) was so convoluted that it was 
nearly impossible to keep track of the allocated block pointers, since 
they would be suffled back and forth between some stack-like structures as 
the thing worked.

I thought it would very helpful if Valgrind could provide one or both of 
the following:

- The last place in the program where a pointer to a particular block was 
used. I think this would be useful for people wishing to fine-tune their 
memory usage in general. It would also show a candidate location for that 
missing free()...

- The last place where a pointer to a block was clobbered/lost, which is a 
probable location for the actual leak

As for the implementation (warning: rampant ignorance ahead), it seems to 
me that something similar to the valid-value tracking mechanism could be 
used:

- have a bitmap (P-bits ?) that marks certain addresses as pointers.

- when a block is allocated, mark the location of the returned pointer in 
the bitmap.

- when a pointer is copied, adjust the bitmap to include the new address.

- when a pointer is used mark the place in the block metadata. This might 
be more accurate if any access to a block was tracked in general.

- when the stack is adjusted/blocks freed/etc check all marked locations 
and update the metadata for any blocks that lost a pointer. If we had a 
pointer counter it might even be possible to detect memory leaks on the 
fly.

- same for any clobbered pointers. No idea how to deal with the common 
ptr++ case. Maybe show this info only for definitely lost blocks ?

Then corroborate the info collected above with the definite/potential loss 
info to increase accuracy (maybe for both ?).

I understand that this could be quite slow, but I think it would be worth 
it. Even a slowdown similar to the one induced by --track-origins=yes 
would be acceptable IMO. And it could always be optional...

Does this sound stupid or doable ?


Regards,

Theodoros Kalamatianos