Open yiyuaner opened 1 year ago
Thanks for filing this and for your patience.
I'm able to reproduce this bug with the latest version of ikos.
I'm tracing this down.
This is a segfault. The problem is in line 1455 in:
More specifically, ar_value->type()
is the call that segfaults.
The pointer is not null. ar_value
has the value 0x71
which seems a pointer to a very low memory location if I'm interpreting this right.
Looking at how ar_value
is defined in line 1452 (that's the path taken in this case) takes me to:
var
at the return point is indeed 0x71
. Perhaps this is a problem with either the implementation of the symbols table or the values being put in it? I'd appreciate a second pair of eyes here.
@ivanperez-keera
The problem is that llvm_value
is never translated, i.e., this->_variables.find(llvm_value) == this->_variables.end()
in the following code fragment:
Notable, the assertion in the function translate_value
is not compiled into the binary of ikos-analyzer
(even in cmake Debug build), hence we have missed the assertion error:
We can try dumping out llvm_value
:
(gdb) p llvm_value->dump()
%24 = zext i1 undef to i8, !dbg !8997
However, in my debugging, the function FunctionImporter::translate_cast
is never called on the llvm_value
. Why is that? Isn't IKOS translate each instruction one by one?
Also, not sure if this has something to do with the llvm version. When I raised the issue, the bitcode is compiled by clang-9, but the latest ikos uses llvm 14.
I don't think it's due to the version of LLVM. I was able to reproduce this with the latest version, which uses LLVM 14.
I was running ikos using a bitcode file compiled from clang-9.
The command is:
The stack trace is:
The bitcode file is attached for your reference. redis-cli.zip