[LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.
Michael Ilseman
michael at lunarg.com
Wed May 4 12:58:38 PDT 2011
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.
On Wed, May 4, 2011 at 12:48 PM, Ralf Karrenberg <Chareos at gmx.de> wrote:
> 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
>
>
> Am 04.05.2011 18:15, schrieb Michael Ilseman:
>>
>> 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
>>>
>>
>> _______________________________________________
>> 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