Dear All,
I'm getting the following assertion from a program I've written:
/home/vadve/criswell/src/llvm22/lib/VMCore/Value.cpp:57: virtual llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed.
This occurs when I free a Module (the program uses an auto_ptr() to the Module, and the auto_ptr() moves out of scope).
It looks like the code that frees a BasicBlock frees all of its instructions in order without regards to the def-use chains. However, the Value class's destructor has the assertion that the Value has no uses.
Is the assertion an error, or should BasicBlock's deallocate instructions so that there are no dangling def-use chains?
-- John T.
You probably have an instruction that you removed from the module but didn't delete. The module dtor works fine: it uses 'dropAllReferences' to clear the operands of instructions before deleting the instructions themselves.
-Chris
Chris Lattner wrote:
Dear All,
I'm getting the following assertion from a program I've written:
/home/vadve/criswell/src/llvm22/lib/VMCore/Value.cpp:57: virtual
llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a
value is destroyed!"' failed.
This occurs when I free a Module (the program uses an auto_ptr() to
the
Module, and the auto_ptr() moves out of scope).
It looks like the code that frees a BasicBlock frees all of its
instructions in order without regards to the def-use chains. However,
the Value class's destructor has the assertion that the Value has no
uses.
Is the assertion an error, or should BasicBlock's deallocate
instructions so that there are no dangling def-use chains?
You probably have an instruction that you removed from the module but
didn't delete. The module dtor works fine: it uses
'dropAllReferences' to clear the operands of instructions before
deleting the instructions themselves.
Okay. I wasn't aware I had to delete unneeded values as well as remove them. I'll try that.
Thanks.
-- John T.
You probably have an instruction that you removed from the module but
didn't delete. The module dtor works fine: it uses
'dropAllReferences' to clear the operands of instructions before
deleting the instructions themselves.
Okay. I wasn't aware I had to delete unneeded values as well as remove
them. I'll try that.
The convention is that 'remove' unlinks the object from the IR, and 'erase' does remove and deletes the result.
If someone wants to clarify this behavior in LLVM Programmer’s Manual — LLVM 16.0.0git documentation, it would be nice 
-Chris
Chris Lattner wrote:
You probably have an instruction that you removed from the module but
didn't delete. The module dtor works fine: it uses
'dropAllReferences' to clear the operands of instructions before
deleting the instructions themselves.
Okay. I wasn't aware I had to delete unneeded values as well as
remove
them. I'll try that.
The convention is that 'remove' unlinks the object from the IR, and
'erase' does remove and deletes the result.
If someone wants to clarify this behavior in http://llvm.org/docs/ProgrammersManual.html#common
, it would be nice
No, I understood that part (granted, I read DoxyGen). The part I didn't understand is that I'm required to erase an instruction that should have no more uses before deleting the Module.
If I get time, I can try to add some text about it.
-- John T.
That's what the assertion is telling you (poorly) :). It is saying that there is something that uses a value that is attempting to be deleted. It doesn't know the context, so it can't tell you that the user is something that was unlinked but not deleted.
If you write your code as an llvm pass, you should automatically get notified of this stuff in a debug build. If you can't do that, manually interfacing to the LeakDetector can help.
-Chris
Chris Lattner wrote:
The convention is that 'remove' unlinks the object from the IR, and
'erase' does remove and deletes the result.
If someone wants to clarify this behavior in http://llvm.org/docs/ProgrammersManual.html#common
, it would be nice
No, I understood that part (granted, I read DoxyGen). The part I
didn't
understand is that I'm required to erase an instruction that should
have
no more uses before deleting the Module.
That's what the assertion is telling you (poorly) :). It is saying
that there is something that uses a value that is attempting to be
deleted. It doesn't know the context, so it can't tell you that the
user is something that was unlinked but not deleted.
If you write your code as an llvm pass, you should automatically get
notified of this stuff in a debug build. If you can't do that,
manually interfacing to the LeakDetector can help.
It is an LLVM pass, it's a debug build, and the only assertion I got was the one in ~Value().
Should there have been an earlier assertion?
-- John T.
If you write your code as an llvm pass, you should automatically get
notified of this stuff in a debug build. If you can't do that,
manually interfacing to the LeakDetector can help.
It is an LLVM pass, it's a debug build, and the only assertion I got was
the one in ~Value().
Should there have been an earlier assertion?
You load a module, run your pass (which leaks an instruction) from the passmgr, then delete the module?
-Chris
Chris Lattner wrote:
If you write your code as an llvm pass, you should automatically get
notified of this stuff in a debug build. If you can't do that,
manually interfacing to the LeakDetector can help.
It is an LLVM pass, it's a debug build, and the only assertion I got
was
the one in ~Value().
Should there have been an earlier assertion?
You load a module, run your pass (which leaks an instruction) from the
passmgr, then delete the module?
Yes, that's what the code was doing.
-- John T.
If you're sure that you're leaking in instruction and it isn't getting caught, please try to figure out why leak detector isn't seeing it. LeakDetector is a really trivial class: if you add a breakpoint to addGarbage/removeGarbage, you should be able to see what isn't happening.
-Chris