search for: leakdetector

...ontext &Context, >> ArrayRef<Metadata *> MDs, >> MDNodeFwdDecl *MDNode::getTemporary(LLVMContext &Context, >> ArrayRef<Metadata *> MDs) { >> MDNodeFwdDecl *N = new (MDs.size()) MDNodeFwdDecl(Context, MDs); >> - LeakDetector::addGarbageObject(N); >> + LeakDetector::addGarbageObject((MDNode*)N); >> return N; >> } > > Sorry, after more extensive testing, this doesn't work. It looks like > you need to add const MDNode * overloads to addGarbageObject() adding > them for addGarbageObje...

...+564,7 @@ MDNode *MDNode::getMDNode(LLVMContext &Context, ArrayRef<Metadata *> MDs, MDNodeFwdDecl *MDNode::getTemporary(LLVMContext &Context, ArrayRef<Metadata *> MDs) { MDNodeFwdDecl *N = new (MDs.size()) MDNodeFwdDecl(Context, MDs); - LeakDetector::addGarbageObject(N); + LeakDetector::addGarbageObject((MDNode*)N); return N; } I'm in favor of committing this. -Tom > > On 2014 Dec 10, at 15:57, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > > >> > >> On 2014 Dec 10, at 14:08, To...

Can anyone help with these crazy linking errors?? /home/kgibbs/CS321/CVS/llvm/lib/Debug/vmcore.o(.gnu.linkonce.t._ZN4llvm12Lea kDetector16addGarbageObjectEPKNS_5ValueE+0xd): In function `llvm::LeakDetector::addGarbageObject(llvm::Value const*)': /usr/include/c++/3.2.1/bits/stl_pair.h:148: undefined reference to `llvm::LeakDetector::addGarbageObjectImpl(llvm::Value const*)' /home/kgibbs/CS321/CVS/llvm/lib/Debug/vmcore.o(.gnu.linkonce.t._ZN4llvm12Lea kDetector19removeGarbageObjectEPKNS_5Value...

...) from /lib64/libc.so.6 >>> #1 0x00007ffff59f6348 in abort () from /lib64/libc.so.6 >>> #2 0x00007ffff59edb96 in __assert_fail_base () from /lib64/libc.so.6 >>> #3 0x00007ffff59edc42 in __assert_fail () from /lib64/libc.so.6 >>> #4 0x00007ffff3a30e92 in llvm::LeakDetectorImpl<void>::addGarbage(void const*) [clone .part.19] () from /opt/buildbot/lib/libLLVM-3.6svn.so >>> #5 0x00007ffff3a30fd3 in llvm::LeakDetector::addGarbageObjectImpl(void*) () from /opt/buildbot/lib/libLLVM-3.6svn.so >>> #6 0x00007ffff3a40eed in llvm::MDNode::getTemporary(...

You'll need to include the "support" library to resolve these LeakDetector symbols. You can do this by either placing the path to "support.o" or -lsupport on your link line (in your Makefile). Note that if you use the -l option, you'll likely need to use -L<path> as well to tell the linker where to find "libsupport.a" (file included by t...

...lto:llvmdev-admin at cs.uiuc.edu] On > Behalf Of Reid Spencer > Sent: Tuesday, December 09, 2003 8:36 PM > To: Kevin Gibbs > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Linking Errors? > > You'll need to include the "support" library to resolve these > LeakDetector symbols. You can do this by either placing the path to > "support.o" or -lsupport on your link line (in your Makefile). Note > that if you use the -l option, you'll likely need to use -L<path> as > well to tell the linker where to find "libsupport.a" (file in...

I am seeing the following assertion in leak detector. /llvm/lib/VMCore/LeakDetector.cpp:43: void<unnamed>::LeakDetectorImpl<T>::addGarbage(const T*) [with T = void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"' failed. I am creating a list of instructions using BuildMI() and adding them to a basic block using BB->insert(). I am...

On Wed, Jun 3, 2009 at 5:10 PM, Manjunath Kudlur <keveman at gmail.com> wrote: > I am seeing the following assertion in leak detector. > > /llvm/lib/VMCore/LeakDetector.cpp:43: > void<unnamed>::LeakDetectorImpl<T>::addGarbage(const T*) [with T = > void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"' > failed. > > I am creating a list of instructions using BuildMI() and adding them > to a basic bloc...

...0 0x00007ffff59f4c39 in raise () from /lib64/libc.so.6 > #1 0x00007ffff59f6348 in abort () from /lib64/libc.so.6 > #2 0x00007ffff59edb96 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x00007ffff59edc42 in __assert_fail () from /lib64/libc.so.6 > #4 0x00007ffff3a30e92 in llvm::LeakDetectorImpl<void>::addGarbage(void const*) [clone .part.19] () from /opt/buildbot/lib/libLLVM-3.6svn.so > #5 0x00007ffff3a30fd3 in llvm::LeakDetector::addGarbageObjectImpl(void*) () from /opt/buildbot/lib/libLLVM-3.6svn.so > #6 0x00007ffff3a40eed in llvm::MDNode::getTemporary(llvm::LLVMContex...

...g BB->insert() Manjunath On Wed, Jun 3, 2009 at 5:26 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Wed, Jun 3, 2009 at 5:10 PM, Manjunath Kudlur <keveman at gmail.com> wrote: >> I am seeing the following assertion in leak detector. >> >> /llvm/lib/VMCore/LeakDetector.cpp:43: >> void<unnamed>::LeakDetectorImpl<T>::addGarbage(const T*) [with T = >> void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"' >> failed. >> >> I am creating a list of instructions using BuildMI() and adding them...

...d Spencer wrote: > I have a "first version" of Stacker up and running. Structurally its a > lot like llvm-as. When I run it, I get: > Leaked objects found: after running pass 'Function Pass Manager' > LLVM Value subclasses leaked: This is coming from the LLVM "LeakDetector" stuff. The idea is that you are not supposed to create random instructions or basic blocks, then leave them hanging around: you should put them into a module somewhere. :) > Note that the supposed list of "LLVM Value subclasses leaked" is empty. > Its followed up by a SIGSE...

I have a "first version" of Stacker up and running. Structurally its a lot like llvm-as. When I run it, I get: Leaked objects found: after running pass 'Function Pass Manager' LLVM Value subclasses leaked: Note that the supposed list of "LLVM Value subclasses leaked" is empty. Its followed up by a SIGSEGV at AsmWriter.cpp:754 presumably because I have a BasicBlock

...ot usable in this context... > > You can use Function::getBasicBlockList(). That list supports fully general list operations like "insert", so you can just plop it in wherever you'd like it. methods like the basic block constructor or BasicBlock::setParent muck around with the LeakDetector. I don't know what the LeakDetector is - does Stéphane need to do something like this too? Ciao, Duncan.

Hi, I finally took the time to track down the remaining memory leaks beside the LeakDetector objects and TypeMaps/ValueMaps I already knew about. It turns out almost all of them came from the command line options module, so I cleaned up the patch for LeakDetector and made a new patch for CommandLine. The patches are attached to this message. That got rid of all but 4 leaks I'm gett...

...39;t know the context, so it can't tell you that the > user is something that was unlinked but not deleted. > > If you write your code as an llvm pass, you should automatically get > notified of this stuff in a debug build. If you can't do that, > manually interfacing to the LeakDetector can help. > It is an LLVM pass, it's a debug build, and the only assertion I got was the one in ~Value(). Should there have been an earlier assertion? -- John T. > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc....

Chris Lattner wrote: >>> If you write your code as an llvm pass, you should automatically get >>> notified of this stuff in a debug build. If you can't do that, >>> manually interfacing to the LeakDetector can help. >>> >>> >> It is an LLVM pass, it's a debug build, and the only assertion I got >> was >> the one in ~Value(). >> >> Should there have been an earlier assertion? >> > > You load a module, run your pass (which leak...

Hi, In my code generator, I need to prepare a block and add instructions to it, then insert this block in a function defined later (that is I cannot create the function at the beginning stage become some info are not available yet). I tried to create a block without any "parent" (BasicBlock::Create(getGlobalContext(), "init"), fill it, but how to link it with the created

On Jun 13, 2010, at 2:12 AM, Stéphane Letz wrote: > Hi, > > In my code generator, I need to prepare a block and add instructions to it, then insert this block in a function defined later (that is I cannot create the function at the beginning stage become some info are not available yet). I tried to create a block without any "parent" (BasicBlock::Create(getGlobalContext(),

...-------- Module.cpp GlobalVariable *ilist_traits<GlobalVariable>::createSentinel() { GlobalVariable *Ret = new GlobalVariable(Type::getInt32Ty(getGlobalContext()), false, GlobalValue::ExternalLinkage); // This should not be garbage monitored. LeakDetector::removeGarbageObject(Ret); return Ret; } GlobalAlias *ilist_traits<GlobalAlias>::createSentinel() { GlobalAlias *Ret = new GlobalAlias(Type::getInt32Ty(getGlobalContext()), GlobalValue::ExternalLinkage); // This should not be garbage monitored. Lea...

On Fri, 19 Nov 2004, Morten Ofstad wrote: > I finally took the time to track down the remaining memory leaks beside > the LeakDetector objects and TypeMaps/ValueMaps I already knew about. It > turns out almost all of them came from the command line options module, > so I cleaned up the patch for LeakDetector and made a new patch for > CommandLine. The patches are attached to this message. Looks great, applied: http://mai...