[LLVMdev] Memory leak?

[Rafael Espindola]

On 12 June 2010 01:10, Neal  N. Wang <neal.wang at gmail.com> wrote:
> Hi folk,
>
> I get the following stack trace and do have any clue how to fix the problem.
>
> 0  opt               0x087ecc99
> 1  opt               0x087ed265
> 2                    0xb7f6a400 __kernel_sigreturn + 0
> 3  opt               0x086d4198
> llvm::LeakDetector::addGarbageObject(llvm::Value const*) + 29
> 4  opt               0x0872945f llvm::Instruction::Instruction(llvm::Type
> const*, unsigned int, llvm::Use*, unsigned int, llvm::Instruction*) + 109
> 5  opt               0x083d208b
> llvm::UnaryInstruction::UnaryInstruction(llvm::Type const*, unsigned int,
> llvm::Value*, llvm::Instruction*) + 75
> 6  opt               0x0873e46b llvm::CastInst::CastInst(llvm::Type const*,
> unsigned int, llvm::Value*, llvm::Twine const&, llvm::Instruction*) + 57
> 7  opt               0x0873124d llvm::BitCastInst::BitCastInst(llvm::Value*,
> llvm::Type const*, llvm::Twine const&, llvm::Instruction*) + 65
>
>
>
> I insert extra two instructions to a byte code, the corresponding code is
> quite simple:
> LoadInst* ptrVal = new LoadInst(ptr, "foobar", false, next);
> CastInst* ptrCast = new BitCastInst(ptrVal, charPtrType, "cast1", next);
>
> If I comment out the CastInst statement, it runs fine. Any hint what is
> wrong?


I have seen cases like this caused by a failure to destroy a pool
allocated object. Very small changes to the input cause the addresses
to change and it "works". What version of llvm are you using? If it is
current (svn), I think you will have to hunt the bug down with gdb.
Look for the same address being added as garbage twice for example.

> Thanks,
> Neal
>


Cheers,
-- 
Rafael Ávila de Espíndola