[LLVMdev] How can I see what opt tries to delete at the end of a pass?

Hal Finkel hfinkel at anl.gov
Sat Feb 4 11:06:19 PST 2012


On Sat, 2012-02-04 at 12:58 -0500, Griffin Wright wrote:
> 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?

The invalid reads and writes could be an array-indexing error. Run
valgrind with --db-attach=yes --track-origins=yes; that should give you
more info on the uninitialized value error and should allow you to look
at the state of the program in gdb whenever an error is detected.

 -Hal 

> 
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory




More information about the llvm-dev mailing list