[LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.

Michael Ilseman michael at lunarg.com
Wed May 4 09:15:46 PDT 2011


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
>




More information about the llvm-dev mailing list