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-04 16:15 UTC

[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
>

Ralf Karrenberg

2011-May-04 18:48 UTC

head link

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

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>

Michael Ilseman

2011-May-04 19:58 UTC

head link

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

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
>>
>

Possibly Parallel Threads

Search for more seemingly similar 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.

Possibly Parallel Threads