[buttproblem]

I'm curious about how you use this during debugging, would you mind elaborating on what language(s) you're using the call-graph from?

I'm wondering because I've been studying building automated program reasoning tools and have found that even just creating the call-graph is difficult: I imagine the end result potentially confusing the user because it is either incomplete or overly pessimistic. For example, the LLVM call-graph (apart from not being in the language directly used by the developer) does not include edges from indirect calls because their targets cannot be resolved (so it is incomplete). Alternatively, in the case where you don't know which function is called you can just add an edge to every function in the program (pessimistically).

The same story goes for the dependency graph.

I myself am a bit pessimistic myself about more powerful software understanding tools probably because I've been working on the problem for too long. It's particularly difficult because the languages end up being too difficult to analyze, and there is a huge engineering effort in creating an analyzer which is tuneable to handle various language features efficiently. But, if you have a particular problem and a particular (subset) of the language it ends up working nicely.

[mannykannot]

I have done this for C code. I will sometimes print off sections of a call tree and make notes on it to keep track of what I have found about what updates what as I work backwards from the point of failure.

I have also used the 'call hierarchy' and 'find usages' features in IntelliJ to help me navigate around Java code.

I appreciate your point that more dynamic and feature-rich languages are much more difficult (if not impossible) to analyze statically.