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

Michael Ilseman michael at lunarg.com
Tue May 3 16:18:32 PDT 2011


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}



More information about the llvm-dev mailing list