Possible memory leak in LLVM 2.5


I’m current using LLVM 2.5 to JIT code in a event driven language running on a game engine. Haven’t updated to 2.7 yet, but I do intend to.

When checking for memory leaks I found that each time I was calling EE->runFunction after creating a stub function to execute an event, all the pass information was being repeatedly added to PMDataManager.

I have changed addAnalysisImplsPair to the following, which seems to have no side effects with what I am doing. Prior to that, AnalysisImpls contained thousands of entries and each time the vector gets realloced to accommodate more entries we lose a bigger chunk of memory.

void addAnalysisImplsPair(const PassInfo *PI, Pass *P) {

for (std::vector<std::pair<const PassInfo*, Pass*> >::iterator I =

AnalysisImpls.begin(); (I!=AnalysisImpls.end()); ++I)


if (I->first==PI && I->second==P)


// Return, if PassInfo and Pass are already in AnalysisImpls.




std::pair<const PassInfo*, Pass*> pir = std::make_pair(PI,P);



I’m probably doing something funny, or not as intended, but your comments would be appreciated.


I'm unfamiliar with the leak you've just described, but Jeffrey
Yasskin has done a lot of work cleaning up leaks for 2.7 and trunk.

I was just going to mention that unless the function you are calling
via runFunction has a simple prototype that's special cased in
runFunction, it will generate its own stub function for every call.
If you don't want to worry about that, you can call
getPointerToFunction and cast it to the appropriate function pointer
type before calling it yourself.


Hi Reid,

I guess it's not so much a memory leak, as unexpected behaviour, resulting in excessive memory use.

I also call the following after EE->runFunction, which seems to clean up pretty nicely.

   // Delete functions and IR.


Yeah, it sounds like a Java-leak rather than the kind of leak valgrind
would find. We fixed all the valgrind-detected leaks shortly after 2.7
branched, but I don't think I touched this file.

I'm not going to have time to look at this in the near future, but if
you can write a small program that compiles against llvm trunk (2.5 is
too old, and 2.7 is nearly so, unfortunately) and uses increasing
amounts of memory over time just from calling runFunction repeatedly,
you should file a bug at llvm.org/bugs