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}

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

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.

Hi Michael, hi Duncan,

yesterday I stumbled over something that might be related.
At least I could also just be doing some initialization wrong or something in this direction...

In my case, I hit a segfault in PassInfo::isAnalysisGroup() after PassManager.add(myModulePass) is called.
My setup seems fairly simple, the attached code should reproduce the error.

Compile with
g++ test.cpp `llvm-config --cxxflags --ldflags --libs all` -o test

gdb --args ./test
prints the following stack trace:

#0 0x00000000004e35ba in llvm::PassInfo::isAnalysisGroup (this=0x0) at llvm/include/llvm/PassSupport.h:91
#1 0x00000000004e2ffa in llvm::PassInfo::createPass (this=0x0) at llvm/lib/VMCore/Pass.cpp:196
#2 0x00000000004e522e in llvm::PMTopLevelManager::schedulePass (this=0x85eb60, P=0x85ef10) at llvm/lib/VMCore/PassManager.cpp:617
#3 0x00000000004ebcce in llvm::PassManagerImpl::add (this=0x85e9b0, P=0x85ef10) at llvm/lib/VMCore/PassManager.cpp:396
#4 0x00000000004e9735 in llvm::PassManager::addImpl (this=0x7fffffffdd90, P=0x85ef10) at llvm/lib/VMCore/PassManager.cpp:1659
#5 0x00000000004e9884 in llvm::PassManager::add (this=0x7fffffffdd90, P=0x85ef10) at llvm/lib/VMCoree/PassManager.cpp:1672
#6 0x000000000040b9be in main () at test.cpp:32

Best,
Ralf

test.cpp (859 Bytes)

Your constructor is not calling initializeTestMPPass(), and you're
using RegisterPass which I think was deprecated in favor of
INITIALIZE_PASS. You can look at, for example,
lib/Transforms/Scalar/IndVarSimplify.cpp for examples of how to
initialize, e.g. having "INITIALIZE_PASS_DEPENDENCY(LoopInfo)"
sandwiched between BEGIN and END. Note that you'll want a forward
declaration of initializeTestMPPass(), as it won't have a declaration
in include/llvm/InitializePasses.h. These are all the changes I think
I had to make to port my passes to 2.9 from 2.8.

Hi Michael,

thanks a lot. It seems like I missed quite some things when porting to LLVM 2.9. After the changes you suggested, the code works as expected. :slight_smile:
However, I think a segfault is not what should happen there.

Best,
Ralf

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

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