Open Endericedragon opened 5 months ago
We have also encountered this issue. However, it seems to have little impact on our analysis.
We think this issue is caused by subtle and undocumented invariants not being satisfied when using the Rust compiler's query system, leading to an internal compiler error.
It is not easy to pinpoint the problem, but we will work on fixing it in the future.
We tested Rupta on analyzing the substrate-node-template. Although the project itself is not very large, it has many dependencies, resulting in a large number of reachable functions. Consequently, it requires some time and memory to analyze.
Our analysis results differed from yours, which may be due to analyzing different versions of the substrate-node-template. Our test showed more reachable functions than your results, but our analysis took much less time.
I think the long analysis time might be due to insufficient available memory during the analysis. As indicated in your results, it took about 23GB to analyze this project. It is necessary to ensure enough running memory during analysis.
We tested Rupta on analyzing the substrate-node-template. Although the project itself is not very large, it has many dependencies, resulting in a large number of reachable functions. Consequently, it requires some time and memory to analyze.
Our analysis results differed from yours, which may be due to analyzing different versions of the substrate-node-template. Our test showed more reachable functions than your results, but our analysis took much less time.
I think the long analysis time might be due to insufficient available memory during the analysis. As indicated in your results, it took about 23GB to analyze this project. It is necessary to ensure enough running memory during analysis.
Indeed, I am analyzing an older version of substrate node template(which is a fork created in last year). I think I would install more memory on my PC to accelerate that process. Thanks for your reply!
We have also encountered this issue. However, it seems to have little impact on our analysis.
We think this issue is caused by subtle and undocumented invariants not being satisfied when using the Rust compiler's query system, leading to an internal compiler error.
Undocumented, yes. Subtle... not very?
In general, the Rust compiler is designed to issue a "bug" on any question that, during a normal compilation session, you should probably not even be asking. This is a fairly standard "fail fast" stance.
However, there are some questions that are okay to ask, but the answer implies the program should be rejected. When you ask a question, "are these consts equal types?", it is expecting you are using the answer to typecheck and thus reject the program. Then the compiler creates a delayed bug. The compiler asking such a question is deemed "non-buggy" if an error is later issued.
Most of the compiler is not designed to support general analysis of it. It is designed to actually compile programs, and thus to reject incorrect programs. The stable_mir
project is designed to create something that does support general analysis.
Thanks for your rapid fixing work! Eventually I could get the full call graph of Substrate Node Template. However, not only the compiling and analysing cost a lot of time (near 4 hours), but I also received delayed bugs messages after rupta had generated the .dot file and pts information. Here is the bug message I received:
After going through the paper about rupta and the manual, I still do not know what delayed bugs are. Are there code smells in the analyzed crate? Or it is just another bug of rupta?