llvm dev - Feb 2012 - [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>) + 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

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

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

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