What issues does static call graph analysis decipher?

Question

What issues would one hope to find using static call graph analysis on a program? FxCop uses static call graph analysis, what issues does it find using this technique?

http://msdn.microsoft.com/library/bb429476.aspx
http://en.wikipedia.org/wiki/Callgraph

Apologies for my lack of knowledge, I found some information via google, but fear that it is vastly incomplete. Thanks!

Answer 1

This is what I've found:

Call-graphs are used to detect issues in regards to program execution, violation of recommended guidelines, and possible code injection attacks.

By creating a graph of the calling relationships among various methods, it is easy to see where issues may arise at certain times when certain methods are called or how certain methods are called. It's easy to see when a procedure/function may be violating guidelines such as sustaining code modularity. It's easy to see where malicious code could possibly be injected at certain points because of those calling relationships, and how they are structured. In this way, call-graphs provide context to static analysis, producing more accurate results.

Since FxCop uses static call-graphs, it is only able to speculate on the above to a degree.

Answer 2

By itself the call-graph is just that; there are no "wrong" call graphs (unless you have a style check prohibiting recursion).

The real issue is that to understand how code at a point in the program might be problematic, you typically need to understand the shape of the world (what data structures are live, what values they might contain, what relationships they might have) at the moment where that code point is active. The call graph shows how execution can get to the code point of interest, and all the code along that call graph path sets the code execution context. This enables the static analyzer to produce a "context-sensitive" analysis, which gives much more accurate answers.

This leads to a second problem: how does one get an accurate call graph? If you have a direct call of B from A, it is easy to write down, "A calls B" and feel this is an accurate call-graph fact. But if A makes an call through an indirect pointer (can you say virtual method dispatch?) suddenly it isn't so clear exactly who A calls; you end up with A-might-call-B1, A-might-call-B2, ... Which one A actually calls in fact depends on the context in which A executes... oops, you need the call graph to manufacture the call graph. The sort of good news is that you build the call graph up from the bottom: "I know this is surely true, so that must be surely true". At places where the analzyer can't figure it out, it generally makes a conservative guess: ("All of these calls might be possible, I can't rule them out"). That conservatism is one of the key causes of the accuracy of your static analyzer.