[LLVMdev] Possible memory leak in LLVM 2.5
Reid Kleckner
rnk at mit.edu
Mon May 17 19:53:09 PDT 2010
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.
Reid
On Mon, May 17, 2010 at 9:27 PM, Rob Grapes <Rob.Grapes at ur.co.nz> wrote:
> Hi,
>
>
>
> 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.
>
> return;
>
> }
>
> }
>
> std::pair<const PassInfo*, Pass*> pir = std::make_pair(PI,P);
>
> AnalysisImpls.push_back(pir);
>
> }
>
>
>
> I’m probably doing something funny, or not as intended, but your comments
> would be appreciated.
>
>
>
> Rob.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
More information about the llvm-dev
mailing list