Michael Ilseman
2011-May-03 23:18 UTC
[LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.
When migrating my project to 2.9, I've encountered a strange segfault where if a ModulePass's getAnalysisUsage adds LoopInfo and DominatorTree, then llvm::PMTopLevelManager::findAnalysisUsage will segfault. What's odd is that if I rearrange this (add required for DominatorTree before LoopInfo), it does not segfault. I realize that LoopInfo requires and preserves DominatorTree, but this behavior is strange. All my other passes migrated fine (after adding in code to do the initializations), but perhaps I'm still not initializing everything properly?. Below is an example program and it's stack trace and debug info. #include "llvm/Pass.h" #include "llvm/PassManager.h" #include "llvm/Analysis/Dominators.h" #include "llvm/Analysis/LoopInfo.h" using namespace llvm; // Forward decl namespace llvm { void initializeFooPass(PassRegistry&); } // end namespace llvm namespace { class Foo : public ModulePass { public: Foo() : ModulePass(ID) { initializeFooPass(*PassRegistry::getPassRegistry()); } ~Foo() { } static char ID; bool runOnModule(Module&); void print(std::ostream&, const Module*) const; void getAnalysisUsage(AnalysisUsage&) const; }; } // end namespace bool Foo::runOnModule(Module &M) { return false; } void Foo::getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<LoopInfo>(); AU.addRequired<DominatorTree>(); } void Foo::print(std::ostream&, const Module*) const { } char Foo::ID = 0; INITIALIZE_PASS_BEGIN(Foo, "foo", "foo bar", true, true) INITIALIZE_PASS_DEPENDENCY(LoopInfo) INITIALIZE_PASS_DEPENDENCY(DominatorTree) INITIALIZE_PASS_END(Foo, "foo", "foo bar", true, true) Foo *createFooPass() { return new Foo(); } void runFooPass(Module &M) { PassManager PM; PM.add(createFooPass()); PM.run(M); } Program received signal SIGSEGV, Segmentation fault. #0 0x0832312f in llvm::PMTopLevelManager::findAnalysisUsage (this=0x86f798c, P=0x892bfc0) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:577 #1 0x08322cfb in llvm::PMTopLevelManager::setLastUser (this=0x86f798c, AnalysisPasses=..., P=0x892d2e0) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:516 #2 0x083275f5 in llvm::MPPassManager::addLowerLevelRequiredPass (this=0x885cc60, P=0x892d2e0, RequiredPass=0x892bfc0) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1608 #3 0x08324cef in llvm::PMDataManager::add (this=0x885cc70, P=0x892d2e0, ProcessAnalysis=true) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:989 #4 0x08327f11 in llvm::ModulePass::assignPassManager (this=0x892d2e0, PMS=..., PreferredType=llvm::PMT_ModulePassManager) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1768 #5 0x08329b11 in llvm::PassManagerImpl::addTopLevelPass (this=0x885cab8, P=0x892d2e0) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:423 #6 0x0832339f in llvm::PMTopLevelManager::schedulePass (this=0x885cb8c, P=0x892d2e0) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:639 #7 0x083299dc in llvm::PassManagerImpl::add (this=0x885cab8, P=0x892d2e0) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:396 #8 0x083279e5 in llvm::PassManager::addImpl (this=0xbffe9578, P=0x892d2e0) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1659 #9 0x08327b0a in llvm::PassManager::add (this=0xbffe9578, P=0x892d2e0) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1672 #10 0x08089480 in runFooPass (M=...) at <...>/Hello.h:56 ... At that point, the variable "P" is $9 = {_vptr.Pass = 0x0, Resolver = 0x0, PassID = 0x8533e00, Kind llvm::PT_Function}
Duncan Sands
2011-May-04 06:59 UTC
[LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.
Hi Michael,> When migrating my project to 2.9, I've encountered a strange segfault > where if a ModulePass's getAnalysisUsage adds LoopInfo and > DominatorTree, then llvm::PMTopLevelManager::findAnalysisUsage will > segfault.I suggest you build LLVM with assertions enabled - then you should get a helpful error message rather than a segfault. I think you are not allowed to use LoopInfo from a ModulePass, but I don't recall the details. This came up several times already on the mailing list, so I suggest you search the archives. Ciao, Duncan. What's odd is that if I rearrange this (add required for> DominatorTree before LoopInfo), it does not segfault. I realize that > LoopInfo requires and preserves DominatorTree, but this behavior is > strange. All my other passes migrated fine (after adding in code to do > the initializations), but perhaps I'm still not initializing > everything properly?. Below is an example program and it's stack trace > and debug info. > > #include "llvm/Pass.h" > #include "llvm/PassManager.h" > #include "llvm/Analysis/Dominators.h" > #include "llvm/Analysis/LoopInfo.h" > > using namespace llvm; > > // Forward decl > namespace llvm { > void initializeFooPass(PassRegistry&); > } // end namespace llvm > > namespace { > class Foo : public ModulePass { > public: > Foo() : ModulePass(ID) { > initializeFooPass(*PassRegistry::getPassRegistry()); > } > > ~Foo() { } > > static char ID; > bool runOnModule(Module&); > void print(std::ostream&, const Module*) const; > void getAnalysisUsage(AnalysisUsage&) const; > }; > } // end namespace > > bool Foo::runOnModule(Module&M) { > return false; > } > > void Foo::getAnalysisUsage(AnalysisUsage&AU) const { > AU.addRequired<LoopInfo>(); > AU.addRequired<DominatorTree>(); > } > > void Foo::print(std::ostream&, const Module*) const { } > > char Foo::ID = 0; > INITIALIZE_PASS_BEGIN(Foo, "foo", "foo bar", true, true) > INITIALIZE_PASS_DEPENDENCY(LoopInfo) > INITIALIZE_PASS_DEPENDENCY(DominatorTree) > INITIALIZE_PASS_END(Foo, "foo", "foo bar", true, true) > > Foo *createFooPass() { > return new Foo(); > } > > void runFooPass(Module&M) > { > PassManager PM; > PM.add(createFooPass()); > PM.run(M); > } > > > Program received signal SIGSEGV, Segmentation fault. > > #0 0x0832312f in llvm::PMTopLevelManager::findAnalysisUsage > (this=0x86f798c, P=0x892bfc0) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:577 > #1 0x08322cfb in llvm::PMTopLevelManager::setLastUser > (this=0x86f798c, AnalysisPasses=..., P=0x892d2e0) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:516 > #2 0x083275f5 in llvm::MPPassManager::addLowerLevelRequiredPass > (this=0x885cc60, P=0x892d2e0, RequiredPass=0x892bfc0) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1608 > #3 0x08324cef in llvm::PMDataManager::add (this=0x885cc70, > P=0x892d2e0, ProcessAnalysis=true) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:989 > #4 0x08327f11 in llvm::ModulePass::assignPassManager (this=0x892d2e0, > PMS=..., PreferredType=llvm::PMT_ModulePassManager) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1768 > #5 0x08329b11 in llvm::PassManagerImpl::addTopLevelPass > (this=0x885cab8, P=0x892d2e0) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:423 > #6 0x0832339f in llvm::PMTopLevelManager::schedulePass > (this=0x885cb8c, P=0x892d2e0) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:639 > #7 0x083299dc in llvm::PassManagerImpl::add (this=0x885cab8, > P=0x892d2e0) at<...>/llvm-2.9/lib/VMCore/PassManager.cpp:396 > #8 0x083279e5 in llvm::PassManager::addImpl (this=0xbffe9578, > P=0x892d2e0) at<...>/llvm-2.9/lib/VMCore/PassManager.cpp:1659 > #9 0x08327b0a in llvm::PassManager::add (this=0xbffe9578, > P=0x892d2e0) at<...>/llvm-2.9/lib/VMCore/PassManager.cpp:1672 > #10 0x08089480 in runFooPass (M=...) at<...>/Hello.h:56 > ... > > At that point, the variable "P" is > > $9 = {_vptr.Pass = 0x0, Resolver = 0x0, PassID = 0x8533e00, Kind > llvm::PT_Function} > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Michael Ilseman
2011-May-04 16:15 UTC
[LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.
Thanks for the response. I do have assertions enabled, and none of them are getting hit. I did do a search of the mailing list for the past year (approximately) before writing my email, and what I found was that you should be allowed to use LoopInfo and other analysis function passes from a module pass, with the only difference being that getAnalysis is passed the function. The example code I posted conforms to all of the suggestions from the mailing list. Also, the same code (with modifications w.r.t. 2.8 initialization) works just fine in 2.8, and works fine in 2.9 with the rearranging I mentioned in my email. My concern is that having certain rearrangements segfault (even with assertions enabled), while others succeed may be due to a misunderstanding on my part of how initialization is done properly in 2.9. I have tried to model my code (and the example code given) after how the passes in lib/Transforms/Scalar are modeled. On Wed, May 4, 2011 at 12:59 AM, Duncan Sands <baldrick at free.fr> wrote:> Hi Michael, > >> When migrating my project to 2.9, I've encountered a strange segfault >> where if a ModulePass's getAnalysisUsage adds LoopInfo and >> DominatorTree, then llvm::PMTopLevelManager::findAnalysisUsage will >> segfault. > > I suggest you build LLVM with assertions enabled - then you should get a > helpful error message rather than a segfault. I think you are not allowed > to use LoopInfo from a ModulePass, but I don't recall the details. This > came up several times already on the mailing list, so I suggest you search > the archives. > > Ciao, Duncan. > > What's odd is that if I rearrange this (add required for >> DominatorTree before LoopInfo), it does not segfault. I realize that >> LoopInfo requires and preserves DominatorTree, but this behavior is >> strange. All my other passes migrated fine (after adding in code to do >> the initializations), but perhaps I'm still not initializing >> everything properly?. Below is an example program and it's stack trace >> and debug info. >> >> #include "llvm/Pass.h" >> #include "llvm/PassManager.h" >> #include "llvm/Analysis/Dominators.h" >> #include "llvm/Analysis/LoopInfo.h" >> >> using namespace llvm; >> >> // Forward decl >> namespace llvm { >> void initializeFooPass(PassRegistry&); >> } // end namespace llvm >> >> namespace { >> class Foo : public ModulePass { >> public: >> Foo() : ModulePass(ID) { >> initializeFooPass(*PassRegistry::getPassRegistry()); >> } >> >> ~Foo() { } >> >> static char ID; >> bool runOnModule(Module&); >> void print(std::ostream&, const Module*) const; >> void getAnalysisUsage(AnalysisUsage&) const; >> }; >> } // end namespace >> >> bool Foo::runOnModule(Module&M) { >> return false; >> } >> >> void Foo::getAnalysisUsage(AnalysisUsage&AU) const { >> AU.addRequired<LoopInfo>(); >> AU.addRequired<DominatorTree>(); >> } >> >> void Foo::print(std::ostream&, const Module*) const { } >> >> char Foo::ID = 0; >> INITIALIZE_PASS_BEGIN(Foo, "foo", "foo bar", true, true) >> INITIALIZE_PASS_DEPENDENCY(LoopInfo) >> INITIALIZE_PASS_DEPENDENCY(DominatorTree) >> INITIALIZE_PASS_END(Foo, "foo", "foo bar", true, true) >> >> Foo *createFooPass() { >> return new Foo(); >> } >> >> void runFooPass(Module&M) >> { >> PassManager PM; >> PM.add(createFooPass()); >> PM.run(M); >> } >> >> >> Program received signal SIGSEGV, Segmentation fault. >> >> #0 0x0832312f in llvm::PMTopLevelManager::findAnalysisUsage >> (this=0x86f798c, P=0x892bfc0) at >> <...>/llvm-2.9/lib/VMCore/PassManager.cpp:577 >> #1 0x08322cfb in llvm::PMTopLevelManager::setLastUser >> (this=0x86f798c, AnalysisPasses=..., P=0x892d2e0) at >> <...>/llvm-2.9/lib/VMCore/PassManager.cpp:516 >> #2 0x083275f5 in llvm::MPPassManager::addLowerLevelRequiredPass >> (this=0x885cc60, P=0x892d2e0, RequiredPass=0x892bfc0) at >> <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1608 >> #3 0x08324cef in llvm::PMDataManager::add (this=0x885cc70, >> P=0x892d2e0, ProcessAnalysis=true) at >> <...>/llvm-2.9/lib/VMCore/PassManager.cpp:989 >> #4 0x08327f11 in llvm::ModulePass::assignPassManager (this=0x892d2e0, >> PMS=..., PreferredType=llvm::PMT_ModulePassManager) at >> <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1768 >> #5 0x08329b11 in llvm::PassManagerImpl::addTopLevelPass >> (this=0x885cab8, P=0x892d2e0) at >> <...>/llvm-2.9/lib/VMCore/PassManager.cpp:423 >> #6 0x0832339f in llvm::PMTopLevelManager::schedulePass >> (this=0x885cb8c, P=0x892d2e0) at >> <...>/llvm-2.9/lib/VMCore/PassManager.cpp:639 >> #7 0x083299dc in llvm::PassManagerImpl::add (this=0x885cab8, >> P=0x892d2e0) at<...>/llvm-2.9/lib/VMCore/PassManager.cpp:396 >> #8 0x083279e5 in llvm::PassManager::addImpl (this=0xbffe9578, >> P=0x892d2e0) at<...>/llvm-2.9/lib/VMCore/PassManager.cpp:1659 >> #9 0x08327b0a in llvm::PassManager::add (this=0xbffe9578, >> P=0x892d2e0) at<...>/llvm-2.9/lib/VMCore/PassManager.cpp:1672 >> #10 0x08089480 in runFooPass (M=...) at<...>/Hello.h:56 >> ... >> >> At that point, the variable "P" is >> >> $9 = {_vptr.Pass = 0x0, Resolver = 0x0, PassID = 0x8533e00, Kind >> llvm::PT_Function} >> _______________________________________________ >> 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 >
Arushi Aggarwal
2011-May-17 19:10 UTC
[LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.
Hi, I am running into the same issue with a module pass, that calls LoopInfo.(does not call DominatorTree) I am using RegisterPass, since it is a dynamically loaded module(as per lib/Transforms/Hello) It does seem possible from the discussion, to use LoopInfo inside a ModulePass. I am wondering what the fix to this problem was. Also, the code works in 2.7.(I did not try 2.8) Thanks, Arushi On Tue, May 3, 2011 at 6:18 PM, Michael Ilseman <michael at lunarg.com> wrote:> When migrating my project to 2.9, I've encountered a strange segfault > where if a ModulePass's getAnalysisUsage adds LoopInfo and > DominatorTree, then llvm::PMTopLevelManager::findAnalysisUsage will > segfault. What's odd is that if I rearrange this (add required for > DominatorTree before LoopInfo), it does not segfault. I realize that > LoopInfo requires and preserves DominatorTree, but this behavior is > strange. All my other passes migrated fine (after adding in code to do > the initializations), but perhaps I'm still not initializing > everything properly?. Below is an example program and it's stack trace > and debug info. > > #include "llvm/Pass.h" > #include "llvm/PassManager.h" > #include "llvm/Analysis/Dominators.h" > #include "llvm/Analysis/LoopInfo.h" > > using namespace llvm; > > // Forward decl > namespace llvm { > void initializeFooPass(PassRegistry&); > } // end namespace llvm > > namespace { > class Foo : public ModulePass { > public: > Foo() : ModulePass(ID) { > initializeFooPass(*PassRegistry::getPassRegistry()); > } > > ~Foo() { } > > static char ID; > bool runOnModule(Module&); > void print(std::ostream&, const Module*) const; > void getAnalysisUsage(AnalysisUsage&) const; > }; > } // end namespace > > bool Foo::runOnModule(Module &M) { > return false; > } > > void Foo::getAnalysisUsage(AnalysisUsage &AU) const { > AU.addRequired<LoopInfo>(); > AU.addRequired<DominatorTree>(); > } > > void Foo::print(std::ostream&, const Module*) const { } > > char Foo::ID = 0; > INITIALIZE_PASS_BEGIN(Foo, "foo", "foo bar", true, true) > INITIALIZE_PASS_DEPENDENCY(LoopInfo) > INITIALIZE_PASS_DEPENDENCY(DominatorTree) > INITIALIZE_PASS_END(Foo, "foo", "foo bar", true, true) > > Foo *createFooPass() { > return new Foo(); > } > > void runFooPass(Module &M) > { > PassManager PM; > PM.add(createFooPass()); > PM.run(M); > } > > > Program received signal SIGSEGV, Segmentation fault. > > #0 0x0832312f in llvm::PMTopLevelManager::findAnalysisUsage > (this=0x86f798c, P=0x892bfc0) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:577 > #1 0x08322cfb in llvm::PMTopLevelManager::setLastUser > (this=0x86f798c, AnalysisPasses=..., P=0x892d2e0) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:516 > #2 0x083275f5 in llvm::MPPassManager::addLowerLevelRequiredPass > (this=0x885cc60, P=0x892d2e0, RequiredPass=0x892bfc0) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1608 > #3 0x08324cef in llvm::PMDataManager::add (this=0x885cc70, > P=0x892d2e0, ProcessAnalysis=true) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:989 > #4 0x08327f11 in llvm::ModulePass::assignPassManager (this=0x892d2e0, > PMS=..., PreferredType=llvm::PMT_ModulePassManager) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1768 > #5 0x08329b11 in llvm::PassManagerImpl::addTopLevelPass > (this=0x885cab8, P=0x892d2e0) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:423 > #6 0x0832339f in llvm::PMTopLevelManager::schedulePass > (this=0x885cb8c, P=0x892d2e0) at > <...>/llvm-2.9/lib/VMCore/PassManager.cpp:639 > #7 0x083299dc in llvm::PassManagerImpl::add (this=0x885cab8, > P=0x892d2e0) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:396 > #8 0x083279e5 in llvm::PassManager::addImpl (this=0xbffe9578, > P=0x892d2e0) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1659 > #9 0x08327b0a in llvm::PassManager::add (this=0xbffe9578, > P=0x892d2e0) at <...>/llvm-2.9/lib/VMCore/PassManager.cpp:1672 > #10 0x08089480 in runFooPass (M=...) at <...>/Hello.h:56 > ... > > At that point, the variable "P" is > > $9 = {_vptr.Pass = 0x0, Resolver = 0x0, PassID = 0x8533e00, Kind > llvm::PT_Function} > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110517/4a31e7b5/attachment.html>
Fabian Scheler
2012-Mar-07 20:48 UTC
[LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.
Hi, folks! Are there any news regarding the findAnalysis-issue. This week I started to port my project from LLVM 2.7 to LLVM 3.0 and ran into it yesterday. I have no clue how to resolve it. How did you "make it go away"? BTW: Is there a helpful documentation how all these INITIALIZE_PASS-macros shall be used? Ciao, Fabian
Apparently Analagous Threads
- [LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.
- [LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.
- [LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.
- [LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.
- [LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.