How to avoid memory leaks

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)

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();

Err, shouldn't you delete fn here? I'm pretty sure that this just
removes the function from the module.

fn = cast<Function>(module->getOrInsertFunction(name, fnType));
fillFunction(fn); //Fill function with some blocks and instructions..
}

Reid

I think you need to call "llvm::Function::deleteBody() first"

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();

Err, shouldn't you delete fn here? I'm pretty sure that this just
removes the function from the module.

Doxygen says that:
"eraseFromParent - This method unlinks 'this' from the containing
module and deletes it."

so it should be fine just calling erase.

fn = cast<Function>(module->getOrInsertFunction(name, fnType));
fillFunction(fn); //Fill function with some blocks and instructions..
}

Reid

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

- Anders

I think you need to call "llvm::Function::deleteBody() first"

Nope, ~Function calls dropAllReferences() the same as deleteBody() does.

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.