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
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
Chris, It's the 2.0. I'll try the head as soon as I can (I installed the 2.0 via macports). All started because I was not sure if deleting the ExecutionEngine is all I have to do to cleanup the LLVM stuff. Cheers, Paolo On Jul 15, 2007, at 9:33 PM, Chris Lattner wrote:> 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/_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 checkIs 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/