SUMMARY I'm trying to narrow down a use-after-free bug with interned strings in Python. It is fairly obvious what is happening, someone gave a dynamically allocated string to the Python interpreter with a promise that its lifetime would exceed that of the interpreter (so the string data could be shared), and later deallocated the string. The three stack traces I get (allocation, deallocation and use) show what is happening, but it is difficult for me to find the point where the string is given to Python -- the function to intern the string is called quite often, so I can't just easily break there. What would be nice would be a user request to attach an auxiliary stack trace to a block of memory so more lifetime events can be traced -- in my case I could for example save the stack trace for the call that adds the string to the list of interned strings, so I can see which context made the lifetime promise that later on wasn't kept.
(In reply to Simon Richter from comment #0) > The three stack traces I get (allocation, deallocation and use) show what is > happening, but it is difficult for me to find the point where the string is > given to Python -- the function to intern the string is called quite often, > so I can't just easily break there. Waiting for valgrind to provide some support to record auxiliary stack traces as you suggest, what you might do is to capture this stack trace and print it together with the ptr for the memory allocated and given to python. Then when valgrind reports a 'use after free' error, you can search in the program output the last stack trace that mention this pointer.