[LLVMdev] 2.9 segfault when requesting for both LoopInfo and DominatorTree analyses.
Ralf Karrenberg
Chareos at gmx.de
Wed May 4 11:48:04 PDT 2011
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
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.cpp
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110504/55715d30/attachment.ksh>
More information about the llvm-dev
mailing list