[cfe-dev] Understanding BuryPointer and leak detection

[Mike Lewis]

Hi all,

I'm experimenting with libclang on Windows as a mechanism for runtime compilation of C code. So far results are encouraging, but I'm encountering a lot of rogue memory usage the longer the host app runs (and the more Clang code I call). Right now I'm relying on the Visual C++ CRT leak check functionality to monitor memory leakage; it's crude and simplistic but highly reliable once you compensate for a couple of quirks. I should state up-front that I can confirm my results of leakage using other tools as well.

The CRT leak check is finding several hundred KB of leaks each time I compile a module using the embedded Clang. Strategic placement of memory breakpoints suggests that the bulk of these are due to things that are (directly or otherwise) owned by something that eventually winds up handed off to the BuryPointer() function.

I've skimmed the list history for the origins of BuryPointer, but I have to confess I'm still rather confused. From an outsider's perspective, it seems like BuryPointer is just a way to work around having to actually clean up resources that have nontrivial ownership semantics. I gather that the purpose is to make the memory *look* like it isn't leaked by ensuring that the pointers are still reachable. However, this doesn't really change the fact that the memory is essentially no longer owned by anything (semantically) and is, at least conceptually, a genuine leak.

Given that my experiments show memory usage increasing linearly with the number of times I invoke libclang to do a compilation, I'm guessing that this is actually a genuine problem and that BuryPointer() is papering over the symptoms for certain leak checking tools.


So, three questions:

- Is my understanding of BuryPointer() correct, or is there some complexity I'm not seeing as an (admittedly naïve) outsider?

- Given that this represents a very real upper bound on how many times my host app can do compilations, is there any recourse for reclaiming this memory in some fashion?

- Would there be interest in me contributing patches to address these leaks (and others I've found in both Clang and LLVM), presuming that there is agreement that it's a problem?




Thanks,


- Mike




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141107/85e84246/attachment.html>