thr3ads.net - llvm dev - [LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses. [May 2011]

If this information is useful, please help other people find it:
Share via:

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

head link

[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

head link

[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

head link

[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

head link

[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

Search for more reasonably related threads

llvm dev - May 2011 - [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.

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

Apparently Analagous Threads