[LLVMdev] How can I see what opt tries to delete at the end of a pass?
grwright at umich.edu
Sat Feb 4 09:58:26 PST 2012
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?
==16471== Conditional jump or move depends on uninitialised value(s)
==16471== at 0xEA56580: llvm::IntervalIterator<llvm::BasicBlock,
llvm::GraphTraits<llvm::Inverse<llvm::BasicBlock*> > >::~IntervalIterator()
==16471== by 0xEA5549E:
==16471== by 0xF04F976:
==16471== by 0xF04FB30: llvm::FPPassManager::runOnModule(llvm::Module&)
==16471== by 0xF04FE1B: llvm::MPPassManager::runOnModule(llvm::Module&)
==16471== by 0xF0502D1: llvm::PassManagerImpl::run(llvm::Module&)
==16471== by 0xF0507C2: llvm::PassManager::run(llvm::Module&)
==16471== by 0x807D514: main (opt.cpp:689)
==16471== Uninitialised value was created by a stack allocation
==16471== at 0xEA55407:
On Fri, 3 Feb 2012 13:44:10 -0800, Eli Friedman <eli.friedman at gmail.com>
> On Fri, Feb 3, 2012 at 1:20 PM, Griffin Wright <grwright at umich.edu>
>> 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
>> and opt goes to return, I get:
>> While deleting: void %
>> An asserting value handle still pointed to this value!
>> UNREACHABLE executed at
>> On a simple test case, the error becomes 'i32 %' instead of 'void %'.
>> cannot for the life of me figure out what is happening. I'm not
>> anything extra internal to my pass that I can tell, and I'm not sure how
>> 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.
More information about the llvm-dev