How to approach debugging a huge not so familiar code base?

Question

Seldom during working on large scale projects, suddenly you are moved on to a project which is already in maintainance phase.You end up with having a huge code C/C++ code base on your hands, with not much doccumentation about the design.The last person who could give you some knowledge transfer about the code has left the company already and to add to your horrors there is not enough time to get acquainted with the code and develop an understanding of the overall module/s.In this scenario when you are expected to fix bugs(core dumps,functionality,performance problems etc) on the module/s what is the approach that you will take?

So the question is: What are your usual steps for debugging a not so familiar C/C++ code base when trying to fix a bug?

EDIT: Enviornment is Linux, but code is ported on Windows too so suggestions for both will be helpful.

Answer 1

If possible, step through it from main() to the problematic area, and follow the execution path. Along the way you'll get a good idea of how the different parts play together.

It could also be helpful to use a static code analysis tool, like CppDepends or even Doxygen, to figure out the relations between modules and be able to view them graphically.

Answer 2

Use a pen and paper, or images/graphs/charts in general, to figure out which parts belong where and draw some arrows and so on.

This helps you build and see the image that will then be refined in your mind as you become more comfortable with it.

I used a similar approach attacking a hellish system that had 10 singletons all #including each other. I had to redraw it a few times in order to fit everything, but seeing it in front of you helps.

It might also be useful to use Graphviz when constructing dependency graphs. That way you only have to list everything (in a text file) and then the tool will draw the (often unsightly) picture. (This is what I did for the #include dependencies in above syste,)