debuginfo: Assertion in ValueHandleBase::ValueIsDeleted() when using -O

[michaelwoerister]

Sometimes when enabling debug info and optimizations at the same time, rustc dies with an assertion in the LLVM method ValueHandleBase::ValueIsDeleted():

While deleting: metadata %
An asserting value handle still pointed to this value!
UNREACHABLE executed at /home/sc/projects/rust/rust/src/llvm/lib/IR/Value.cpp:632!

This is one the major issues keeping debug info from being end-user ready (see #9770).

I was already able to identify the cause for the assertion:
The failure itself says that a value handle still points to the metadata node that is currently being deleted. This leaked handle is created in LLVM's DwarfDebug::collectDeadVariables() on a path that is only hit with optimizations activated. That's why the assertion is never triggered when compiling something without the -O flag.

The memory leak occurs because the method cannot handle duplicate entries in the list of subprograms in the compile unit. This is a bug in LLVM: http://llvm.org/bugs/show_bug.cgi?id=16017
It's not clear yet how it will be fixed exactly.

But the issue should also be tackled on our side: That LLVM reacts with a memory leak to invalid input is unfortunate but it's still us that generate the invalid input. The main issue here is that some functions are translated more than once (see issue #7349) and thus they are also added to the debug info function list more than once.

I think the best way to fix this issue is to fix #7349. This way we don't have to wait for LLVM to take care of their side. Also, the folks at LLVM might decide to just assert on invalid input, so we have take care of this anyway.

[michaelwoerister]

A little update on this: The actual memory leak has been fixed in LLVM (with this change: llvm-mirror/llvm@d56c9db) and the assertion should thus not be triggered any more, once we use a new version of LLVM.

It's still a problem/code smell that the same function is translated more than once. It's easy enough to fix this on the debug info side (just keep track of which functions have been handled already and skip otherwise) but I guess it would be better to fix the underlying issue (#7349).

[michaelwoerister]

I'm closing this issue because it doesn't occur anymore---the memory corruption in LLVM has been fixed. I just left it open because there is also a related (non-debuginfo) issue on the rustc-side, but this issue is already documented properly in #7349. Having a second issue as reminder is redundant.