[LLVMdev] How to avoid memory leaks

[Jeffrey Yasskin]

I fixed a leak that manifests like this in
http://llvm.org/viewvc/llvm-project?rev=99160&view=rev. Are you synced
past there? That leak would only show up in this way if you create at
least 1,382 distinct ConstantFPs, which leaks me to believe you didn't
show us all of your code. When diagnosing a leak, it's important to
have all of the context. You should also run valgrind with
--num-callers=50 to get more of the stack trace. When it cuts off
inside of LLVM, that doesn't help in reproducing the problem.

On Tue, Mar 23, 2010 at 4:04 AM, Gabi <bugspynet at gmail.com> wrote:
> Hi
> I get huge memory leaks using LLVM IRBuilder (trunk version)
>
> Basically I recreate a function over and over again, and pretty sure
> that my code doesn't cause the leak
> while(true)
> {
>  Function *fn = module->getFunction(name);
>    if (fn)
>       fn->eraseFromParent();
>
>    fn =  cast<Function>(module->getOrInsertFunction(name, fnType));
>    fillFunction(fn); //Fill function with some blocks and instructions..
> }
>
> Is there any documentation guideline on how to manage memory with
> LLVM? . I am kind of lost here. I tried anything I could but it seems
> the leaks won't go away
>
> Valgrind gives me lots of ..
>
> 110,560 bytes in 1,382 blocks are possibly lost in loss record 176 of 181
> ==17474==    at 0x4C2596C: operator new(unsigned long) (vg_replace_malloc.c:220)
> ==17474==    by 0x90A922: llvm::User::operator new(unsigned long,
> unsigned int) (in /home/gabi/vgen/Debug/vgen)
> ==17474==    by 0x88A5B6: llvm::ConstantFP::get(llvm::LLVMContext&,
> llvm::APFloat const&) (in /home/gabi/vgen/Debug/vgen)
> ==17474==    by 0x925E17: llvm::ConstantFoldBinaryInstruction(unsigned
> int, llvm::Constant*, llvm::Constant*) (in /home/gabi/vgen/Debug/vgen)
> ==17474==    by 0x889587: llvm::ConstantExpr::getTy(llvm::Type const*,
> unsigned int, llvm::Constant*, llvm::Constant*, unsigned int) (in
> /home/gabi/vgen/Debug/vgen)
> ==17474==    by 0x423030:
> llvm::ConstantFolder::CreateFSub(llvm::Constant*, llvm::Constant*)
> const (ConstantFolder.h:58)
> ==17474==    by 0x423F7E: llvm::IRBuilder<true, llvm::ConstantFolder,
> llvm::IRBuilderDefaultInserter<true> >::CreateFSub(llvm::Value*,
> llvm::Value*, llvm::Twine const&)
>
> and also...
> ==17474== 2,880 bytes in 40 blocks are possibly lost in loss record 155 of 181
> ==17474==    at 0x4C2596C: operator new(unsigned long) (vg_replace_malloc.c:220)
> ==17474==    by 0x90A922: llvm::User::operator new(unsigned long,
> unsigned int) (in /home/gabi/vgen/Debug/vgen)
> ==17474==    by 0x88423B: llvm::ConstantInt::get(llvm::LLVMContext&,
> llvm::APInt const&) (in /home/gabi/vgen/Debug/vgen)
> ==17474==    by 0x8843B4: llvm::ConstantInt::get(llvm::IntegerType
> const*, unsigned long, bool) (in /home/gabi/vgen/Debug/vgen)
>
> --
> Regards,
> Gabi
>
> http://bugspy.net
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>