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 ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
