Closed ghost closed 8 years ago
the problem at its base is that libvex was not designed to be a static analysis tool, it was designed to be an instrumentation tool, so it will freak out very badly (like so) if you feed it any bad instruction. CFGFast uses a technique where it guesses the addresses of functions, and if it gets it wrong and hits a bad address, this will happen.
However, part of our patches to VEX are making it so that when this happens, instead of just exiting (and taking the python interpreter with it!), it raises a flag that turns into a python exception which can be caught by analysis. Long story short, this printout shouldn't be fatal to any angr analysis, it should just catch the exception and keep chugging along until it finishes.
Yeah, it's pretty minor, not a show stopper by any means. Just thought I'd let you guys know. Thanks for the quick response!
@haxmeadroom i want to kown you how to deal with this problem ,beacause when i annlyses some large binaries,it will print this wrong like yours .thanks
@hanchaoqiang, check out this FAQ entry: https://github.com/angr/angr-doc/blob/master/docs/faq.md#why-am-i-getting-terrifying-error-messages-from-libvex-printed-to-stderr
As rhelmot said above, this is not an error; it's an expected situation during CFG generation.
Have you run across this one before? I got it with a CFGFast of a large binary (I'd include it if it weren't so large). The analysis appears to continue.