Griffin Wright
2012-Feb-03 21:20 UTC
[LLVMdev] How can I see what opt tries to delete at the end of a pass?
Hello, I've been stuck with a problem for about a month, and it has stumped everyone in my lab. I have a function pass that runs, and when it finishes and opt goes to return, I get: While deleting: void % An asserting value handle still pointed to this value! UNREACHABLE executed at /x/grwright/llvm/llvm-2.9/lib/VMCore/Value.cpp:569! On a simple test case, the error becomes 'i32 %' instead of 'void %'. I cannot for the life of me figure out what is happening. I'm not deleting anything extra internal to my pass that I can tell, and I'm not sure how to go about debugging it. All I get from output/gdb is along the lines of what you see below. Is there a way to see a breakdown of what exactly opt is doing, value by value, after it hits return at the end of opt.cpp? Thanks! -Griffin Wright While deleting: void % An asserting value handle still pointed to this value! UNREACHABLE executed at /x/grwright/llvm/llvm-2.9/lib/VMCore/Value.cpp:569! 0 libLLVM-2.9.so 0x569fa56b 1 libLLVM-2.9.so 0x569fa2f8 2 0x55573400 __kernel_sigreturn + 0 3 libc.so.6 0x57422d52 abort + 386 4 libLLVM-2.9.so 0x569e60d4 llvm::SmallVector<char, 64u>::~SmallVector() + 0 5 libLLVM-2.9.so 0x5655ee2e llvm::ValueHandleBase::ValueIsDeleted(llvm::Value*) + 662 6 libLLVM-2.9.so 0x5655d1ec llvm::Value::~Value() + 58 7 libLLVM-2.9.so 0x561f0041 llvm::User::~User() + 93 8 libLLVM-2.9.so 0x56502d89 llvm::Instruction::~Instruction() + 121 9 libLLVM-2.9.so 0x5650551f llvm::CallInst::~CallInst() + 57 10 libLLVM-2.9.so 0x563db671 llvm::ilist_node_traits<llvm::Instruction>::deleteNode(llvm::Instruction*) + 30 11 libLLVM-2.9.so 0x563dac80 llvm::iplist<llvm::Instruction, llvm::ilist_traits<llvm::Instruction>>::erase(llvm::ilist_iterator<llvm::Instruction>) + 4812 libLLVM-2.9.so 0x5646cc37 llvm::iplist<llvm::Instruction, llvm::ilist_traits<llvm::Instruction>>::erase(llvm::ilist_iterator<llvm::Instruction>,llvm::ilist_iterator<llvm::Instruction>) + 49 13 libLLVM-2.9.so 0x5646c7a0 llvm::iplist<llvm::Instruction, llvm::ilist_traits<llvm::Instruction> >::clear() + 102 14 libLLVM-2.9.so 0x5646b420 llvm::BasicBlock::~BasicBlock() + 314 15 libLLVM-2.9.so 0x5646cdb2 llvm::ilist_node_traits<llvm::BasicBlock>::deleteNode(llvm::BasicBlock*) + 30 16 libLLVM-2.9.so 0x5646c9a8 llvm::iplist<llvm::BasicBlock, llvm::ilist_traits<llvm::BasicBlock>>::erase(llvm::ilist_iterator<llvm::BasicBlock>) + 4817 libLLVM-2.9.so 0x5646b58f llvm::BasicBlock::eraseFromParent() + 77 18 libLLVM-2.9.so 0x564b9b11 llvm::Function::dropAllReferences() + 159 19 libLLVM-2.9.so 0x5652fc59 llvm::Module::dropAllReferences() + 81 20 libLLVM-2.9.so 0x5652eaf2 llvm::Module::~Module() + 50 21 opt 0x08081e36 std::auto_ptr<llvm::Module>::~auto_ptr() + 36 22 opt 0x0807d5a4 main + 5045 23 libc.so.6 0x5740bbd6 __libc_start_main + 230 24 opt 0x0806de41
Eli Friedman
2012-Feb-03 21:44 UTC
[LLVMdev] How can I see what opt tries to delete at the end of a pass?
On Fri, Feb 3, 2012 at 1:20 PM, Griffin Wright <grwright at umich.edu> wrote:> > Hello, > > I've been stuck with a problem for about a month, and it has stumped > everyone in my lab. I have a function pass that runs, and when it finishes > and opt goes to return, I get: > > While deleting: void % > An asserting value handle still pointed to this value! > UNREACHABLE executed at /x/grwright/llvm/llvm-2.9/lib/VMCore/Value.cpp:569! > > On a simple test case, the error becomes 'i32 %' instead of 'void %'. I > cannot for the life of me figure out what is happening. I'm not deleting > anything extra internal to my pass that I can tell, and I'm not sure how to > go about debugging it. All I get from output/gdb is along the lines of > what you see below. > > Is there a way to see a breakdown of what exactly opt is doing, value by > value, after it hits return at the end of opt.cpp?Given your stack trace, all that is happing is that opt is deleting the module. I'm not sure what you mean by a breakdown. The assertion indicates either there's memory corruption or an AssertingVH is somehow leaking. If you haven't yet, I'd suggest trying valgrind. -Eli
Duncan Sands
2012-Feb-04 08:44 UTC
[LLVMdev] How can I see what opt tries to delete at the end of a pass?
Hi Griffin, if you are completely stuck, upload all the code and instructions for how to reproduce somewhere, and if you are lucky someone here may try to debug it for you. Ciao, Duncan.> I've been stuck with a problem for about a month, and it has stumped > everyone in my lab. I have a function pass that runs, and when it finishes > and opt goes to return, I get: > > While deleting: void % > An asserting value handle still pointed to this value! > UNREACHABLE executed at /x/grwright/llvm/llvm-2.9/lib/VMCore/Value.cpp:569! > > On a simple test case, the error becomes 'i32 %' instead of 'void %'. I > cannot for the life of me figure out what is happening. I'm not deleting > anything extra internal to my pass that I can tell, and I'm not sure how to > go about debugging it. All I get from output/gdb is along the lines of > what you see below. > > Is there a way to see a breakdown of what exactly opt is doing, value by > value, after it hits return at the end of opt.cpp? > > Thanks! > -Griffin Wright > > While deleting: void % > An asserting value handle still pointed to this value! > UNREACHABLE executed at /x/grwright/llvm/llvm-2.9/lib/VMCore/Value.cpp:569! > 0 libLLVM-2.9.so 0x569fa56b > 1 libLLVM-2.9.so 0x569fa2f8 > 2 0x55573400 __kernel_sigreturn + 0 > 3 libc.so.6 0x57422d52 abort + 386 > 4 libLLVM-2.9.so 0x569e60d4 llvm::SmallVector<char, 64u>::~SmallVector() + > 0 > 5 libLLVM-2.9.so 0x5655ee2e > llvm::ValueHandleBase::ValueIsDeleted(llvm::Value*) + 662 > 6 libLLVM-2.9.so 0x5655d1ec llvm::Value::~Value() + 58 > 7 libLLVM-2.9.so 0x561f0041 llvm::User::~User() + 93 > 8 libLLVM-2.9.so 0x56502d89 llvm::Instruction::~Instruction() + 121 > 9 libLLVM-2.9.so 0x5650551f llvm::CallInst::~CallInst() + 57 > 10 libLLVM-2.9.so 0x563db671 > llvm::ilist_node_traits<llvm::Instruction>::deleteNode(llvm::Instruction*) > + 30 > 11 libLLVM-2.9.so 0x563dac80 llvm::iplist<llvm::Instruction, > llvm::ilist_traits<llvm::Instruction> >> ::erase(llvm::ilist_iterator<llvm::Instruction>) + 48 > 12 libLLVM-2.9.so 0x5646cc37 llvm::iplist<llvm::Instruction, > llvm::ilist_traits<llvm::Instruction> >> ::erase(llvm::ilist_iterator<llvm::Instruction>, > llvm::ilist_iterator<llvm::Instruction>) + 49 > 13 libLLVM-2.9.so 0x5646c7a0 llvm::iplist<llvm::Instruction, > llvm::ilist_traits<llvm::Instruction> >::clear() + 102 > 14 libLLVM-2.9.so 0x5646b420 llvm::BasicBlock::~BasicBlock() + 314 > 15 libLLVM-2.9.so 0x5646cdb2 > llvm::ilist_node_traits<llvm::BasicBlock>::deleteNode(llvm::BasicBlock*) + > 30 > 16 libLLVM-2.9.so 0x5646c9a8 llvm::iplist<llvm::BasicBlock, > llvm::ilist_traits<llvm::BasicBlock> >> ::erase(llvm::ilist_iterator<llvm::BasicBlock>) + 48 > 17 libLLVM-2.9.so 0x5646b58f llvm::BasicBlock::eraseFromParent() + 77 > 18 libLLVM-2.9.so 0x564b9b11 llvm::Function::dropAllReferences() + 159 > 19 libLLVM-2.9.so 0x5652fc59 llvm::Module::dropAllReferences() + 81 > 20 libLLVM-2.9.so 0x5652eaf2 llvm::Module::~Module() + 50 > 21 opt 0x08081e36 std::auto_ptr<llvm::Module>::~auto_ptr() + 36 > 22 opt 0x0807d5a4 main + 5045 > 23 libc.so.6 0x5740bbd6 __libc_start_main + 230 > 24 opt 0x0806de41 > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Griffin Wright
2012-Feb-04 17:58 UTC
[LLVMdev] How can I see what opt tries to delete at the end of a pass?
ValGrind gives me some info, but I'm not great at memory stuff, and so I'm not sure what to make of it... This is code that worked for someone 8 months ago, and I'm just trying to get it to run on llvm 2.9 instead of 2.8, so the fact that it hasn't been working is frustrating. Anyway, my issues seem to stem from IntervalIterator, as seen below. I have a lot of similar issues going back to IntervalIterator, generally involving invalid reads and writes of size 4. Any idea what that could mean? Thanks, Griffin ==16471== Conditional jump or move depends on uninitialised value(s) ==16471== at 0xEA56580: llvm::IntervalIterator<llvm::BasicBlock, llvm::Function, llvm::GraphTraits<llvm::BasicBlock*>, llvm::GraphTraits<llvm::Inverse<llvm::BasicBlock*> > >::~IntervalIterator() (IntervalIterator.h:137) ==16471== by 0xEA5549E: llvm::IntervalPartition::runOnFunction(llvm::Function&) (IntervalPartition.cpp:71) ==16471== by 0xF04F976: llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1483) ==16471== by 0xF04FB30: llvm::FPPassManager::runOnModule(llvm::Module&) (PassManager.cpp:1503) ==16471== by 0xF04FE1B: llvm::MPPassManager::runOnModule(llvm::Module&) (PassManager.cpp:1557) ==16471== by 0xF0502D1: llvm::PassManagerImpl::run(llvm::Module&) (PassManager.cpp:1638) ==16471== by 0xF0507C2: llvm::PassManager::run(llvm::Module&) (PassManager.cpp:1682) ==16471== by 0x807D514: main (opt.cpp:689) ==16471== Uninitialised value was created by a stack allocation ==16471== at 0xEA55407: llvm::IntervalPartition::runOnFunction(llvm::Function&) (IntervalPartition.cpp:68) On Fri, 3 Feb 2012 13:44:10 -0800, Eli Friedman <eli.friedman at gmail.com> wrote:> On Fri, Feb 3, 2012 at 1:20 PM, Griffin Wright <grwright at umich.edu>wrote:>> >> Hello, >> >> I've been stuck with a problem for about a month, and it has stumped >> everyone in my lab. I have a function pass that runs, and when it >> finishes >> and opt goes to return, I get: >> >> While deleting: void % >> An asserting value handle still pointed to this value! >> UNREACHABLE executed at >> /x/grwright/llvm/llvm-2.9/lib/VMCore/Value.cpp:569! >> >> On a simple test case, the error becomes 'i32 %' instead of 'void %'.I>> cannot for the life of me figure out what is happening. I'm not >> deleting >> anything extra internal to my pass that I can tell, and I'm not sure how >> to >> go about debugging it. All I get from output/gdb is along the lines of >> what you see below. >> >> Is there a way to see a breakdown of what exactly opt is doing, value by >> value, after it hits return at the end of opt.cpp? > > Given your stack trace, all that is happing is that opt is deleting > the module. I'm not sure what you mean by a breakdown. > > The assertion indicates either there's memory corruption or an > AssertingVH is somehow leaking. If you haven't yet, I'd suggest > trying valgrind. > > -Eli
Possibly Parallel Threads
- [LLVMdev] How can I see what opt tries to delete at the end of a pass?
- [LLVMdev] How can I see what opt tries to delete at the end of a pass?
- [LLVMdev] PLEASE help with Alias Analysis initialization assertion at the end of my pass
- [LLVMdev] Assertion `AA && "AA didn't call InitializeAliasAnalysis in its run method!"' failed.
- [LLVMdev] PLEASE help with Alias Analysis initialization assertion at the end of my pass