[LLVMdev] JIT Leaks?

[Chris Lattner]

On Sun, 15 Jul 2007, Paolo Invernizzi wrote:
> First, I'm not sure if deleting the ExecutionEngine is all I need to
> clean-up... so I started with a minimal test just to check

Is this llvm 2.0 or llvm svn head?  Several minor memory leaks have been 
fixed since llvm 2.0.

-Chris

> int main( int argc, char **argv ){
>     while( true ){
>         Module *M = new Module("M");
>         Function *F =  cast<Function>(M->getOrInsertFunction("F",
> Type::Int32Ty, (Type*)0));
>         BasicBlock *BB = new BasicBlock("BB",F);
>         new ReturnInst( ConstantInt::get(Type::Int32Ty,1), BB );
>         std::vector<GenericValue> Args(0);
>         ExistingModuleProvider *MP = new ExistingModuleProvider(M);
>         ExecutionEngine *EE = ExecutionEngine::create(MP, false);
>         GenericValue GV = EE->runFunction(F, Args);
>         delete EE;
>     }
> }
>
> The memory goes up, and OS X leaks command returns pages of:
>
> Leak: 0x011036b0  size=16
>         0x00000000 0x00000000 0x00000000
> 0x01102988     .............)..
> Leak: 0x011036a0  size=16
>         0x00000000 0x00000000 0x00000000
> 0x01102988     .............)..
> Leak: 0x01103680  size=16
>         0x00000000 0x00000000 0x00000000
> 0x01102c78     ............x,..
> Leak: 0x01103670  size=16
>         0x00000000 0x00000000 0x00000000 0x01102728     ............
> ('..
> Leak: 0x01103640  size=16
>         0x00000000 0x00000000 0x00000000
> 0x01102978     ............x)..
> Leak: 0x01103630  size=16
>         0x00000000 0x00000000 0x00000000
> 0x01103368     ............h3..
> Leak: 0x01103620  size=16
>         0x00000000 0x00000000 0x00000000
> 0x01102a58     ............X*..
> Leak: 0x01103610  size=16
>         0x00000000 0x00000000 0x00000000
> 0x01103368     ............h3..
>
> So all I know is that It's a size 16 leak *grin*.
>
> But MallocDebug reports as leaks
>
> 2.4M start
> 2.4M operator new(unsigned long)
> 2.4M MDmalloc
> 2.4M main
> 2.4M llvm::PMDataManager::add(llvm::Pass*, bool)
> 2.4M llvm::LoopPass::assignPassManager(llvm::PMStack&,
> llvm::PassManagerType)
> 2.4M llvm::LLVMTargetMachine::addPassesToEmitMachineCode
> (llvm::FunctionPassManager&, llvm::MachineCodeEmitter&, bool)
> 2.4M llvm::JIT::JIT[in-charge](llvm::ModuleProvider*,
> llvm::TargetMachine&, llvm::TargetJITInfo&)
> 2.4M llvm::JIT::create(llvm::ModuleProvider*, std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >*)
> 2.4M llvm::FunctionPass::assignPassManager(llvm::PMStack&,
> llvm::PassManagerType)
> 2.4M llvm::ExecutionEngine::create(llvm::ModuleProvider*, bool,
> std::basic_string<char, std::char_traits<char>, std::allocator<char> >*)
> 2.4M _start
> 2.4M 0x1
> 2.4M llvm::PMTopLevelManager::schedulePass(llvm::Pass*)
> 2.4M llvm::FunctionPassManagerImpl::addTopLevelPass(llvm::Pass*)
>
> I hope this is usefull, I'm pretty new to OS X.
>
> Cheers, Paolo Invernizzi
>
> On 14/lug/07, at 22:29, Gordon Henriksen wrote:
>
>> On 2007-07-14, at 13:56, Anton Korobeynikov wrote:
>>
>>>> You can find out what exactly leaks with the help of valgrind.
>>>
>>> It seems, that Paolo is on Mac OS X. No valgrind there :(
>>
>> All is not lost…
>>
>> http://developer.apple.com/documentation/Performance/Conceptual/
>> ManagingMemory/Articles/FindingLeaks.html
>>
>> — Gordon
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/